Card rendering method and device

Abstract

The invention provides a card rendering method and device, and relates to the technical field of terminals. According to the method, all the cards to be drawn can be subjected to security level division according to a certain rule, and the same independent card rendering service process is adopted to complete rendering and drawing of the cards with the same security level, so that complete isolation of data resource spaces among the cards with different security levels is realized, and the application security is further improved. The method comprises the steps that the electronic equipment receives a first operation for creating a first card, the security level of the first card is a first security level, and the first card is drawn by using a first rendering process; a second operation of creating a second card is received, the security level of the second card is a second security level, the second card is drawn by using a second rendering process, the first rendering process and the second rendering process are mutually independent, and the first card and the second card are finally displayed on an interface.

Description

Technical Field

[0001] The present application relates to the field of mobile terminal technology, and in particular to a card rendering method and device. Background Art

[0002] With the continuous development of communication technology, electronic devices (such as smartphones) are becoming more and more popular, diversified, and intelligent. The usability and friendliness of the human-computer interaction interface between users and electronic devices are also receiving more and more attention. Traditional desktops allow users to add component cards to the desktop. Generally, the rendering of cards and the UI process are isolated, but the rendering of all cards is directly implemented using the same rendering process. This results in the rendering card itself inheriting the permissions of the rendering process, which poses a security issue. Summary of the invention

[0003] The embodiment of the present application provides a card rendering method and device. The card rendering method provided by the present application can use different independent rendering service processes to complete the rendering of cards with different security levels, thereby achieving complete isolation of operating environment resource data between cards with different security levels, so that when some card applications are attacked by malicious code, other applications will not be affected, thereby improving the security of the application and user experience.

[0004] In the first aspect, the card rendering method provided by the embodiment of the present application is applied to a first electronic device, including: accepting a first operation of creating a first card, the content of the first card comes from a first application, the security level of the first card is a first security level, and the interface of the first card is drawn by matching to a corresponding first process according to the first security level; accepting a second operation of creating a second card, the content of the second card comes from a second application, the security level of the second card is a second security level, and the interface of the second card is drawn by matching to a corresponding second process according to the second security level. The card obtains the corresponding card security level based on a certain strategy, and cards of the same security level use the same independent card rendering service process for card rendering, wherein the first operation and the second operation can be any form of human-computer interaction operation. In this way, the data resource space between cards of different security levels can be completely isolated from each other through process isolation, thereby improving the security of the card. Since different card data comes from different applications, the application security is further improved.

[0005] In the above embodiment, cards are divided into Class I cards and Class II cards according to security levels. Class I cards are cards of the first security level with the highest security level, and Class II cards are cards of the second security level with a lower security level. The first process is responsible for rendering all Class I cards in the electronic device, and the second process is responsible for rendering all Class II cards in the electronic device. In this way, cards of the same security level are rendered using the same independent card rendering service process, which saves a certain amount of memory resources and realizes the control of the number of processes under the premise of security.

[0006] In the above embodiment, the electronic device needs to obtain the security level of the card to be rendered. In some embodiments, the method includes storing the security level of the card corresponding to the application in the electronic device, the electronic device directly obtains the security level of the first card from the device, and the electronic device directly obtains the security level of the second card from the device. In this way, the device can directly identify the security level of the card to be rendered in any scenario. For example, when the device is disconnected from the network, the security level of the card can also be successfully identified and matched to the corresponding independent card rendering service process to complete the card rendering.

[0007] From the above embodiments, the electronic device needs to obtain the security level of the card to be rendered. In some embodiments, the method includes that the server side stores the card security levels corresponding to all different applications, the electronic device directly sends a security level query request for the first card and the second card to the server side, and the server returns the card security levels corresponding to the first card and the second card respectively; or the server side directly sends the card security levels corresponding to the first card and the second card to the device side for reception. In this way, the card security level information needs to be stored on the server side, which reduces the memory space and computing pressure on the device side on the one hand, and on the other hand, when the device is replaced, the card security level matching strategy of the old device will not change.

[0008] In the above embodiment, the electronic device needs to obtain the security level of the card to be rendered, wherein the application that provides the data source to the card is called the card provider application, the first application is the provider application of the first card, and the second application is the provider application of the second card. Because the card data comes from the provider application, in some embodiments, the provider application and the card security level directly form a corresponding relationship. The device clearly identifies the provider application of the card to be rendered, finds the corresponding card level in the corresponding relationship through the provider application, and then uses an independent card rendering service process that matches the security level to render the card. In this way, the security level of the provider application is the security level of the card, so that the device can obtain the corresponding security level when it learns about the card provider application, and can more intuitively and directly determine the security level of the card according to the content of the application.

[0009] In the above embodiment, the electronic device needs to obtain the security level of the card to be rendered, wherein the application that provides the data source to the card is called the card provider application, the first application is the provider application of the first card, and the second application is the provider application of the second card. In some embodiments, the method includes that the card provider application has different classifications, and common ones are financial management, sports health, audio and video, etc. Different application classifications have different corresponding card levels. The application set and the application classification form a second corresponding relationship, and the application classification and the card security level form a third corresponding relationship. There is at least one application in the application set, and the first application belongs to this application set. According to the second corresponding relationship, the application classification of the corresponding first card provider application is determined, that is, the application classification to which the first application belongs, and then the security level of the first card is determined according to the third corresponding relationship; according to the second corresponding relationship, the application classification of the corresponding second card provider application is determined, that is, the application classification to which the second application belongs; and then the security level of the second card is determined according to the third corresponding relationship. The security levels of the first card and the second card are different. In this way, the card security level can be divided according to the classification of the application, providing a simple method for dividing the card security level. For example, all applications in the financial management application category are strongly related to money transactions and have the highest application security requirements, so the corresponding card security levels are set to the highest first security level.

[0010] In the above embodiment, the electronic device needs to obtain the security level of the card to be rendered. In some embodiments, the method includes carrying the security level information of the card in the application installation package, and the security level of the corresponding card can be obtained by parsing the installation package; the electronic device obtains the security level of the first card by parsing the installation package of the first application, and the electronic device obtains the security level of the second card by parsing the installation package of the second application. In this way, the developer can determine the security level of the card during development according to the development requirements, and the subsequent user can directly match the corresponding independent card rendering service process according to the card security level in the application installation package of the card provider to render the card.

[0011] In the above embodiments, in some embodiments, the security level of the first card can be changed from the first security level to the second security level. The system side may update the corresponding level of the first card from the first security level to the second security level, or the user may set the security level of the first card to the second security level, or the server side may change the card security level. In this way, the security level of the card can be changed according to the actual usage, ensuring the flexibility of the card rendering matching process.

[0012] In combination with some embodiments of the first aspect, in some embodiments, the device receives a third operation to create a third card, the security level of the third card is the first security level, and the third card is drawn using a third rendering process, and the third rendering process is different from the first rendering process and the second rendering process; finally, the third card is displayed on the device interface. The third card data comes from a third application, so the third application is the provider application of the third card. Even if the security levels of the first card and the third card are both the first security level, two completely independent card rendering service processes are still used to draw the two cards respectively. In this way, the cards of the first security level are isolated through processes, and the complete isolation of the data resource space is achieved, further improving the security between the first-level cards.

[0013] In the above embodiments, in some embodiments, the first card data comes from the first application, the second card data comes from the second application, and the third card data comes from the third application. The first application, the second application, and the third application all belong to different applications. In this way, the isolation of the data resource space between the various applications is ensured through the isolation of the card display, further improving the security of the application.

[0014] In the above embodiments, in some embodiments, the rendering capabilities of the first rendering process and the second rendering process are different, and the first rendering process can render more dynamic effects. Different animation characteristics can be generated by setting the animation properties of the control, such as translational animation, transparent animation, looping animation, etc. The setting of some animation properties of the control will have a relatively large impact on the card display and device power consumption. For example, the setting of the transparency of the control needs to be strictly controlled, so some control animation properties are only open to cards with higher card security levels. For example, the first rendering process can render special dynamic effects such as transparent animation and looping animation, but the second rendering process does not have the ability to render these dynamic effects. In this way, different rendering processes have different rendering capabilities, so that different cards can have different card dynamic effects. For cards with higher security, some special dynamic effects can be provided to bring a better visual experience.

[0015] In the above embodiments, in some embodiments, the first display area and the second display area belong to the same application of the electronic device, for example, the first display area is displayed on the negative one screen, and the second display area is on the desktop of the device. In this way, the content display of any card user application on the device can be rendered, so that the card rendering of all applications on the device can improve security according to the security classification method.

[0016] In a second aspect, an embodiment of the present application provides an electronic device, comprising: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the electronic device to execute: the first electronic device determines that an interface of a first card is displayed on a first display area, and an interface of a second card is displayed on a second display area, the content of the first card comes from a first application, and a first process draws the interface of the first card; the content of the second card comes from a second application, and a second process draws the interface of the second card; the card obtains a corresponding card security level based on a certain strategy, the security level of the first card is a first security level, and the security level of the second card is a second security level.

[0017] In the above embodiment, the first security level has the highest security requirement, and the second security level is lower than the first security level; the security level of the first card is equivalent to the security level of the first application, and the security level of the second card is equivalent to the security level of the second application, that is, the security level of the card is equivalent to the security level of the card provider application.

[0018] In combination with some embodiments of the second aspect, in some embodiments, the one or more processors are specifically used to call the computer instructions to enable the electronic device to execute: the cards are divided into Class I cards and Class II cards according to their security levels, the Class I cards being the first security level cards with the highest security level, and the Class II cards being the second security level cards with the lower security level; the first process is responsible for rendering all Class I cards in the electronic device, and the second process is responsible for rendering all Class II cards in the electronic device.

[0019] In combination with some embodiments of the second aspect, in some embodiments, the one or more processors are specifically used to call the computer instruction to cause the electronic device memory to execute: the memory stores the security level of the application corresponding to the card.

[0020] In the above embodiment, the one or more processors are specifically used to call the computer instruction to enable the electronic device memory to execute: directly obtaining the security level of the first card and the security level of the second card from the device memory.

[0021] In combination with some embodiments of the second aspect, in some embodiments, the one or more processors are specifically used to call the computer instruction to enable the electronic device to execute: directly obtain or receive the security level of the first card and the security level of the second card from the server side.

[0022] In combination with some embodiments of the second aspect, in some embodiments, the one or more processors are specifically used to call the computer instruction to cause the electronic device memory to execute: storing a first correspondence list formed between card security levels and applications.

[0023] In combination with some embodiments of the second aspect, in some embodiments, the one or more processors are specifically used to call the computer instructions to cause the electronic device memory to execute: a second correspondence list formed by storing applications and application categories, and a third correspondence list formed by card security levels and application categories.

[0024] In the above embodiment, the one or more processors are specifically used to call the computer instruction to enable the electronic device memory to execute: determining the security level of the corresponding first card according to the first application classification, and determining the security level of the second card according to the second application classification. The security levels of the first card and the second card are different.

[0025] In combination with some embodiments of the second aspect, in some embodiments, the one or more processors are specifically used to call the computer instructions to enable the electronic device to execute: parsing the installation package can obtain the security level of the corresponding card; the electronic device obtains the security level of the first card by parsing the installation package of the first application, and the electronic device obtains the security level of the second card by parsing the installation package of the second application.

[0026] In combination with some embodiments of the second aspect, in some embodiments, the one or more processors are specifically used to call the computer instructions to cause the electronic device to execute: receiving a third operation to create a third card, the third card belongs to a category of cards, and drawing the interface of the third card using a third process.

[0027] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, comprising instructions, which, when executed on an electronic device, enables the electronic device to execute a method as described in any possible implementation of the first and second aspects.

[0028] In a fourth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on an electronic device, enables the electronic device to execute a method as described in any possible implementation of the first and second aspects.

[0029] It is understandable that the electronic device provided in the second aspect, the computer storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the method provided in the embodiment of the present application. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method, which will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 This is a schematic diagram of a terminal hardware structure in an embodiment of the present invention;

[0031] Figure 2 A schematic diagram of a terminal software structure in an embodiment of the present invention;

[0032] Figure 3 This is a schematic diagram of a configuration process of basic application information when publishing an application in an embodiment of the present invention;

[0033] Figure 4 This is an example diagram of a basic application information configuration that needs to be completed when publishing an application in an embodiment of the present invention;

[0034] Figure 5 This is another example diagram of basic information configuration of an application that needs to be completed when publishing an application in an embodiment of the present invention;

[0035] Figure 6 This is another example diagram of basic information configuration of an application that needs to be completed when publishing an application in an embodiment of the present invention;

[0036] Figure 7 A schematic diagram of a card management service (FMS) in an embodiment of the present invention;

[0037] Figure 8 This is a schematic diagram of a card provider in an embodiment of the present invention;

[0038] Fig. 9 A schematic diagram of a card creation implementation principle in an embodiment of the present invention;

[0039] Fig.10 A schematic diagram of a card rendering principle in an embodiment of the present invention;

[0040] Fig.11 For the present invention Fig.10 The card rendering method shown in generates a specific implementation diagram of the card;

[0041] Fig.12 This is another schematic diagram of a card rendering principle in an embodiment of the present invention;

[0042] Fig.13 For the present invention Fig.12 The card rendering method shown in generates a specific implementation diagram of the card;

[0043] Fig.14 This is a schematic diagram of specific steps of another method for implementing card rendering in an embodiment of the present invention;

[0044] Fig.15 The figure is a schematic diagram of specific steps of another method for implementing card rendering in an embodiment of the present invention. DETAILED DESCRIPTION

[0045] Currently, there are more and more types of services provided to users in the application market, including sports and health, learning and education, daily office, photography and beautification, social communication, news reading, practical tools, theme personality, audio and video entertainment, financial management and other services, which meet the various needs of current users.

[0046] In order to better present the service content, it will be displayed in the form of cards / components / display components / display controls / controls / application widgets / plug-ins on the mobile terminal (collectively referred to as "cards"). The card tool component can display the display information of the application, and the user can also trigger the electronic device to directly display the application interface corresponding to the display information by clicking on the component. Through cards, important information or operations of the application can be placed in front, achieving direct service access and reducing the level of experience.

[0047] In common solutions, the card rendering process and UI process are isolated, ensuring that the UI process will not be affected when the rendering process crashes. However, all card rendering processes are performed using the same independent card rendering service process, which ensures the isolation between cards through the virtual machine in the runtime state. If malicious code attacks the virtual machine and makes it unsafe, this rendering method will still make all card rendering unsafe, and the card data resources and states to be rendered and displayed between different applications cannot be guaranteed to be isolated from each other. At the same time, this rendering method also causes all renderings to have the same permissions, and some special cards cannot be provided with the permissions they need.

[0048] Display some application data or provide corresponding services. All component renderings are rendered in one process. Different applications have different security and privacy requirements. For example, financial data security requirements will be higher, and malicious code attacks may cause many problems.

[0049] For example, malicious developers can obtain data to be rendered and displayed by other applications through the same rendering process, causing security issues such as data leakage in third-party applications.

[0050] For example, any third-party application has the permission to obtain the code of any other application. When a malicious developer obtains the rendering permission of other third-party applications, he can arbitrarily modify the display information of other components.

[0051] For another example, a malicious developer may deliberately construct a malicious component that is triggered when a user previews or operates the component, thereby initiating malicious operations inside the mobile phone.

[0052] In each of the above scenarios, there are security issues caused by the non-isolation of rendering processes between different applications.

[0053] In view of this, the present application proposes a system and method for multi-level isolation of display components, which divides the display component cards of the application into different security levels, and allows display component cards with different security levels to be rendered using different rendering processes, thereby ensuring that display component cards with different security level requirements cannot be maliciously read or modified, thereby improving the security of the cards and effectively preventing attacks by malicious developers.

[0054] The multiple involved in the embodiments of the present application refers to greater than or equal to two. It should be noted that the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article, unless otherwise specified, generally indicates that the previous and subsequent associated objects are in an "or" relationship. And in the description of the embodiments of the present application, the words "first", "second", etc. are only used to distinguish the purpose of description, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying order.

[0055] The following describes an electronic device for executing the interface display method provided in an embodiment of the present application, a graphical user interface (GUI) for such an electronic device, and an embodiment for using such an electronic device. In some embodiments of the present application, the electronic device may be a variety of portable terminals including a display screen, such as a mobile phone, a tablet computer, a large-screen device, etc. Exemplary embodiments of portable electronic devices include but are not limited to devices equipped with Or portable electronic devices with other operating systems. The portable electronic devices may also be other more electronic devices, such as digital cameras, smart speakers, vehicle-mounted devices (also referred to as vehicle computers), laptop computers, ultra-mobile personal computers (UMPCs), handheld computers, netbooks, personal digital assistants (PDAs), wearable electronic devices, virtual reality devices and other IOT (internet of things) devices. It should also be understood that in some other embodiments of the present application, the electronic devices may not be portable electronic devices, but smart home devices such as desktop computers with display screens, smart refrigerators with display screens, and smart air conditioners.

[0056] In the embodiments of the present application, "terminal device", "electronic device", "mobile terminal", "terminal" and "device" all have the same meaning and can be interchanged.

[0057] The terms "including" and "having" and any variations thereof mentioned in the description of the embodiments of the present application are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but may optionally include other steps or units that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products or devices.

[0058] It should be noted that, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0059] The application (application, app) involved in the embodiments of the present application is a software application that can realize one or more specific functions. The application mentioned in the present application can be an application pre-installed in the terminal device, or it can be an application downloaded from other networks or installed by other means when the user uses the electronic device.

[0060] The operation interface involved in the embodiments of the present application may also be referred to as a user interface (UI) or a graphical interface, or other names. The operation interface is an interface for human-computer interaction between an electronic device and a user. The electronic device can display and output relevant information through the interface, such as displaying images / text / data, etc., and can also receive user operations through the operation interface, such as touch / click / long press / double-click / drag / type, etc. The commonly used form of user interface is a graphical user interface (GUI), which refers to a user interface related to computer operations displayed in a graphical manner. It can be a visual interface element such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, widgets, etc. displayed on the display screen of an electronic device.

[0061] The interface is a medium interface for interaction and information exchange between the application and the user. Every time a vertical synchronization signal (Vsync-APP) arrives, the electronic device needs to generate the interface of the application for the foreground application. The frequency of the vertical synchronization signal is related to the refresh rate of the screen of the electronic device. For example, the frequency of the vertical synchronization signal is the same as the refresh rate of the screen of the electronic device.

[0062] That is, each time before the electronic device refreshes the content displayed on the screen, it needs to generate the interface of the application for the foreground application, so as to show the newly generated interface of the application to the user when the screen is refreshed.

[0063] The interactive events involved in the embodiments of the present application are the steps for users to perform interface operations. Users can perform operations such as clicking / sliding / touching / double-clicking / zooming / long pressing / dragging, which may trigger application data refresh / application startup / application interface jump / application launch / jump to other applications / data transmission between applications / data transmission between mobile terminals and servers, etc.

[0064] The card component involved in the embodiment of the present application is a form of interface display, which can be embedded in other applications (such as desktop) as part of its interface display and can realize the update of the view. Developers can publish new cards through the card management service module. Cards can not only display text / picture / data information, but also support interactive functions with users, such as refreshing page data / pulling up pages / sending messages, etc.

[0065] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0066] Figure 1 A schematic structural diagram of an electronic device 100 is shown.

[0067] The following is a detailed description of the embodiment using the electronic device 100 as an example. It should be understood that: Figure 1 The electronic device 100 shown is only an example, and the electronic device 100 may have more Figure 1 The more or less components shown in the figure can be combined with two or more components, or can have different component configurations. The various components shown in the figure can be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and / or application specific integrated circuits.

[0068] The electronic device 100 may include at least one of a mobile phone, a foldable electronic device, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, a super mobile personal computer, a netbook, a cellular phone, a personal digital assistant, an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, an in-vehicle device, a smart home device, or a smart city device. The embodiment of the present application does not impose any special restrictions on the specific type of the electronic device 100.

[0069] The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) connector 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0070] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

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

[0072] The processor can generate operation control signals based on instruction opcodes and timing signals to complete the control of instruction fetching and execution.

[0073] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 may be a cache memory. The memory may store instructions or data that have been used or are frequently used by the processor 110. If the processor 110 needs to use the instruction or data, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0074] In some embodiments, the processor 110 may include one or more interfaces. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc. The processor 110 may be connected to a touch sensor, an audio module, a wireless communication module, a display, a camera, and other modules through at least one of the above interfaces.

[0075] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present application is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0076] The USB connector 130 is an interface that complies with USB standard specifications and can be used to connect the electronic device 100 and peripheral devices. Specifically, it can be a Mini USB connector, a Micro USB connector, a USB Type C connector, etc. The USB connector 130 can be used to connect a charger to enable the charger to charge the electronic device 100, and can also be used to connect other electronic devices to enable data transmission between the electronic device 100 and other electronic devices. It can also be used to connect headphones to output audio stored in the electronic device through the headphones. The connector can also be used to connect other electronic devices, such as VR devices. In some embodiments, the standard specifications of the universal serial bus can be USB1.x, USB2.0, USB3.x and USB4.

[0077] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. While the charging management module 140 is charging the battery 142, it may also power the electronic device through the power management module 141.

[0078] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the display screen 194, the camera 193, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be set in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

[0079] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0080] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0081] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0082] The modem processor may include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be sent into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After the low-frequency baseband signal is processed by the baseband processor, it is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 170A, a receiver 170B, etc.), or displays an image or video through a display screen 194. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 110 and be set in the same device as the mobile communication module 150 or other functional modules.

[0083] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), bluetooth low energy (BLE), ultra wide band (UWB), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0084] In some embodiments, the antenna 1 of the electronic device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the electronic device 100 can communicate with the network and other electronic devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

[0085] The electronic device 100 can realize the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or change display information.

[0086] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include one or more display screens 194.

[0087] The electronic device 100 can realize the camera function through the camera module 193, ISP, video codec, GPU, display screen 194, application processor AP, neural network processor NPU, etc.

[0088] The camera module 193 may be used to collect color image data and depth data of the photographed object. The ISP may be used to process the color image data collected by the camera module 193. In some embodiments, the camera module 193 may be composed of a color camera module and a 3D sensing module.

[0089] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos are stored in the external memory card. Or files such as music and videos are transferred from the electronic device to the external memory card.

[0090] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional methods or data processing of the electronic device 100 by running instructions stored in the internal memory 121, and / or instructions stored in a memory provided in the processor.

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

[0092] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 can be arranged in the processor 110.

[0093] The speaker 170A, also called a "speaker", is used to convert an audio electrical signal into a sound signal. The electronic device 100 can listen to music or output an audio signal for a hands-free call through the speaker 170A.

[0094] The receiver 170B, also called a "earpiece", is used to convert audio electrical signals into sound signals. When the electronic device 100 receives a call or voice message, the voice can be received by placing the receiver 170B close to the human ear.

[0095] Microphone 170C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can speak by putting their mouth close to microphone 170C to input the sound signal into microphone 170C. The electronic device 100 can be provided with at least one microphone 170C. In other embodiments, the electronic device 100 can be provided with two microphones 170C, which can not only collect sound signals but also realize noise reduction function. In other embodiments, the electronic device 100 can also be provided with three, four or more microphones 170C to collect sound signals, reduce noise, identify the sound source, realize directional recording function, etc.

[0096] The earphone interface 170D is used to connect a wired earphone and can be a USB interface 130 or a 3.5 mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0097] The pressure sensor 180A is used to sense pressure signals and convert the pressure signals into electrical signals.

[0098] The gyro sensor 180B may be used to determine the motion posture of the electronic device 100 .

[0099] The air pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device 100 calculates the altitude based on the air pressure value measured by the air pressure sensor 180C to assist positioning and navigation.

[0100] The magnetic sensor 180D includes a Hall sensor, and the electronic device 100 can detect the opening and closing of the flip leather case by using the magnetic sensor 180D.

[0101] The acceleration sensor 180E can detect the magnitude of the acceleration of the electronic device 100 in various directions (generally three axes).

[0102] The distance sensor 180F is used to measure the distance.

[0103] The ambient light sensor 180L can be used to sense the brightness of ambient light.

[0104] The fingerprint sensor 180H is used to collect fingerprints.

[0105] The temperature sensor 180J is used to detect the temperature.

[0106] The touch sensor 180K is also called a "touch control device". The touch sensor 180K can be set on the display screen 194. The touch sensor 180K and the display screen 194 form a touch screen, also called a "touch control screen". The touch sensor 180K is used to detect touch operations acting on or near it. The touch sensor can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In other embodiments, the touch sensor 180K can also be set on the surface of the electronic device 100, which is different from the position of the display screen 194.

[0107] Bone conduction sensor 180M can obtain vibration signals.

[0108] The buttons 190 may include a power button, a volume button, etc.

[0109] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback.

[0110] Indicator 192 may be an indicator light, which may be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0111] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes the Android system of the layered architecture as an example to exemplify the software structure of the electronic device 100.

[0112] Figure 2 It is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

[0113] The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into five layers, from top to bottom: application layer, application framework layer, Android runtime (ART) and native C / C++ library, hardware abstract layer (HAL) and kernel layer.

[0114] The application layer can include a series of application packages.

[0115] like Figure 2 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, etc.

[0116] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0117] like Figure 2 As shown, the application framework layer may include a window manager, a content provider, a view system, a resource manager, a notification manager, an activity manager, an input manager, and the like.

[0118] The window manager provides window management services (WMS). WMS can be used for window management, window animation management, surface management, and as a transfer station for the input system.

[0119] Content providers are used to store and retrieve data and make it accessible to applications. This data can include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0120] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0121] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0122] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

[0123] The activity manager can provide activity management services (AMS), which can be used to start, switch, and schedule system components (such as activities, services, content providers, and broadcast receivers) as well as manage and schedule application processes.

[0124] The input manager can provide input management services (IMS), which can be used to manage system input, such as touch screen input, key input, sensor input, etc. IMS takes events from input device nodes and distributes them to appropriate windows through interaction with WMS.

[0125] The Android runtime includes the core library and the Android runtime. The Android runtime is responsible for converting source code into machine code. The Android runtime mainly uses ahead of time (AOT) compilation technology and just in time (JIT) compilation technology.

[0126] The core library is mainly used to provide basic Java class library functions, such as basic data structures, mathematics, IO, tools, databases, networks, etc. The core library provides an API for users to develop Android applications.

[0127] The native C / C++ library can include multiple functional modules, such as surface manager, media framework, libc, OpenGL ES, SQLite, Webkit, etc.

[0128] Among them, the surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. The media framework supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. OpenGL ES provides drawing and operation of 2D graphics and 3D graphics in applications. SQLite provides a lightweight relational database for applications of electronic device 100.

[0129] The hardware abstraction layer runs in user space, encapsulates kernel layer drivers, and provides a calling interface to the upper layer.

[0130] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and sensor driver.

[0131] The following is an illustrative description of the workflow of the software and hardware of the electronic device 100 in conjunction with capturing a photo scene.

[0132] When the touch sensor 180K receives a touch operation, the corresponding hardware interrupt is sent to the kernel layer. The kernel layer processes the touch operation into a raw input event (including touch coordinates, timestamp of the touch operation, and other information). The raw input event is stored in the kernel layer. The application framework layer obtains the raw input event from the kernel layer and identifies the control corresponding to the input event. For example, if the touch operation is a touch single-click operation and the control corresponding to the single-click operation is the control of the camera application icon, the camera application calls the interface of the application framework layer to start the camera application, and then starts the camera driver by calling the kernel layer to capture static images or videos through the camera 193.

[0133] One of the security mechanisms adopted by the electronic device 100 is the sandbox mechanism, which protects the security between applications to the greatest extent. Each independent process runs in an independent sandbox to isolate the user's operating environment and ensure that applications cannot interfere with each other. The core mechanism of the sandbox is standard process isolation, which strictly limits file system permissions. By default, different process sandboxes are confined to their own sandboxes, isolated from each other, and run independently.

[0134] The device in the present invention needs to obtain the security level of the card to be rendered, so as to determine the matching corresponding card rendering service process.

[0135] There are many specific implementation methods for the device to obtain the card security level, which are not limited in this application. The device can obtain the card security level through any internal module analysis, or it can analyze it on the server side and directly feed back the analyzed card security level result to the terminal device side. Here, the card management server is used as an example to illustrate the module for obtaining the card security level.

[0136] In one possible implementation method for obtaining the card security level, when developers publish applications in the application market, they need to fill in the card information. The developer can choose the card security level. The application installation package and the corresponding card security level are uploaded to the server through the background of the application market. The application market not only provides the path for downloading the application installation package on the server, but also provides the corresponding card security information download path. The electronic device can obtain the card security level information corresponding to the installation package through the application market download path. For example, the card information can be<cardname=“com.example.dee”,type=“game”,secure=“first”> The card management service module directly obtains the security level of the card based on the secure field through the card information parsed during downloading.

[0137] In another possible implementation method for obtaining the card security level, the card security level information of the application is encapsulated in a configuration file for application development, and written when the installation package is compiled and generated by the integrated development environment (IDE). For example, for the Android operating system, the Android operating system development tool (Android Studio) can be used as a development IDE, and the developer sets the card security level information of the application when writing code in the IDE. When the IDE compiles and generates an installation package, the IDE can obtain the card security level information of each application installation package and write it into the configuration file. During the download / installation / running process of the application, the terminal device package parser can obtain the card security level information of the application in the application configuration file, and actively transmit or passively request the card security level information corresponding to the application to the card management service module through inter-process communication, so that the card management service module confirms the corresponding card security level.

[0138] In another possible implementation of obtaining the card security level, when the card provider sends the card display data, the card security level information is carried in the field. After receiving the information from the card provider, the card management service module parses the field content of the card security level information.

[0139] In another possible implementation of obtaining the card security level, when the card of the application starts rendering, the card management service module accesses the server through the communication interface and directly obtains the security level information of the current displayed card from the server.

[0140] The card provider application and the card to be displayed are in a one-to-one matching relationship, so the security level of the card is also equivalent to the security level of its provider application. Therefore, in all the above implementations, the security level of the application can be directly set, and the security level of the card provider application is the corresponding card security level.

[0141] In another possible implementation method for obtaining the card security level, a classification security level correspondence list between the card security level information and the classification information of the card provider application is established, and the security level of the card to be rendered is determined by the classification of the provider application. The classification security level correspondence list can be replaced or refreshed, and can be stored on the terminal device side or on the server side. After the device obtains the application classification, it parses the corresponding card security level information according to the correspondence list, so that the card management service module obtains the corresponding card security level. It is also possible that the server parses the corresponding card security level according to the correspondence list, and the card service management module obtains the card security level information corresponding to the application from the cloud by active query or passive reception.

[0142] Exemplarily, the classification of the provider application and the card security level information form a mapping relationship. According to the security level of the card, the cards are divided into two categories: Class I cards and Class II cards, wherein the security level requirement of Class I cards is higher than that of Class II cards.

[0143] Generally, different types of applications can be installed in terminal devices. For example, sports and health (Keep / Huawei Sports and Health), learning and education (Youdao Dictionary / Homework Helper), daily office (WPS Office / CamScanner), photography and beautification (Meitu Xiuxiu / Meian Camera), social communication (WeChat / SMS / Phone), news reading (Today's Headlines / Phoenix News), practical tools (Desktop Time / Daily Alarm Clock), theme personality (Super Wallpaper / Kugou Ringtone), audio and video entertainment (iQiyi / Youku), financial management (A Financial APP / B Securities APP), etc. In general, financial management applications have higher requirements for operating data security. Such applications can be defined as high-security applications. When such applications are used as card providers, the corresponding cards are the highest security level cards. High-security applications generally refer to applications with higher security requirements and require a more secure operating environment. As shown in Table 1, a direct mapping method of card provider applications and card security levels is shown.

[0144]

[0145] Table 1 Correspondence between application classification and card security level List 1

[0146] Exemplarily, the classification of the provider application and the card security level information constitute a mapping relationship. According to the security level of the card, the card can also be divided into three categories: Class I card, Class II card and Class III card, where Class I card has the highest security level and Class III card has the lowest security level. As shown in Table 2, a possible corresponding relationship list is shown.

[0147] Application Classification Card security level Application Examples Financial Management A type of card A Finance, B Securities, C Bank, etc. Sports and health Second Class Cards Huawei Sports Health, Keep, etc. other Three types of cards Calculator, alarm clock, etc.

[0148] Table 2 Correspondence between application classification and card security level List 2

[0149] For example, the card security level is divided into N categories (N>3), and the card provider application is also divided into N categories accordingly, and a corresponding mapping relationship is formed according to the security level of the provider data and the N categories of security levels. Among them, the security level of the first category of cards is the highest, and the security level of the N category of cards is the lowest.

[0150] In another possible implementation of obtaining the card security level, the application package name and the card security level information are stored in a key-value pair structure (Map structure) in an associative manner, including: using the application package name as a key and the card security level information corresponding to the application package name as a value, and storing them in the Map structure. When the application displays the card, the application package name of the card to be displayed is used as a query condition, and the data pair list is searched to obtain the card security level information corresponding to the application package name to be queried.

[0151] In another possible implementation method for obtaining the card security level, the card security level is managed by using a high-security application list. The high-security application list must contain the identification information of the application, such as the application package name, application ID, etc. The terminal device determines whether the content provider application of the card to be displayed is on the high-security application list. If it is on the list, the card is a Class I card, otherwise the card is a Class II card. It should be noted that the high-security application list can be refreshed, or it can be set by the user, or it can be preset by the device by default, or it can be preset when the application is developed. The high-security application list can be saved locally on the terminal device, or it can be stored on the server, and the terminal device obtains it through the server. If the high-security application list is stored on the server, the judgment of whether the application is within the scope of the high-security application list in the above implementation method can be completed on the server side, and the server will directly inform the terminal device card service management module of the judgment result.

[0152] There are many specific implementation methods for setting the card security level, and this application does not limit it.

[0153] like Figure 3 The figure shows an example of the configuration process of basic application information when publishing an application. Developers need to first prepare the materials required for the application, including application icons, application screenshots and videos. Then they need to enter the application information page and configure the basic information of the application on the application information page, including compatible devices, localization basic information, application classification and developer service information.

[0154] like Figure 4 As shown, the configuration of the basic information of the application that needs to be completed (configure the basic information of the application) is exemplarily shown. The developer sets the classification of the application. In order to more accurately locate the classification of the application, the exemplary application market divides the application into several categories, such as the common types: leisure and puzzle, business strategy, sports competition, chess and card games, action shooting, audio and video entertainment, practical tools, social communication, education, news reading, photography and beautification, food, travel navigation, travel accommodation, shopping price comparison, financial management, sports and health, convenient life, theme personality, etc. In order to more accurately locate the classification of the application, the application market classification can be set to several levels. Table 3 exemplarily shows that the application classification is divided into three levels.

[0155]

[0156]

[0157] Table 3 Example of three-level classification of applications

[0158] like Figure 4 As shown, configure the application language, application name, application introduction, etc. in the localizable basic information area, and upload the application materials prepared by the developer. If multiple languages ​​are configured, the developer needs to switch the added language in the "Language" drop-down list. The application name defaults to the application name set when the application is created. The modified application name must comply with the naming rules for the application listing. The application introduction is a brief description of the application's functions, products, etc.

[0159] In an embodiment of a possible implementation of card security level division, the developer selects the name of the application to be released in the application list, and starts to configure the basic information of the application on the application information page corresponding to the application. Fill in the application creation time, software package type, package name, application ID, compatible devices, localizable basic information, etc. The localizable basic information includes the configured application language, application name, and application introduction. The developer selects the most appropriate application classification and clarifies the type of application after review by the application market. The card is a form of information display of the application, so the type of card can be the same as the type of application in the application market. Different security levels are matched according to the application classification. For application classifications with higher information security requirements (such as: financial management applications), the security level of the corresponding card should also be set to high. The application classification matched with the security level here can be the first-level application classification, second-level application classification, third-level application classification, or a more fine-grained application classification in the example of Table 3.

[0160] In one embodiment of the card security level classification, the developer selects the name of the application to be released in the application list, and starts to configure the basic information of the application on the application information page corresponding to the application. Fill in the application creation time, software package type, package name, application ID, supported devices, compatible devices, localizable basic information, etc. Figure 5 As shown in the figure, the localizable basic information includes the configured application language, application name, application description and application security level. Developers select the most appropriate security level in the localizable basic information module. During the application listing process, the application market comprehensively considers the application type and card security level to review the card security level and finally determines the card security level.

[0161] In one embodiment of the card security level classification, the developer selects the name of the application to be released in the application list, and starts to configure the basic information of the application on the application information page corresponding to the application. Fill in the application creation time, software package type, package name, application ID, supported devices, compatible devices, localizable basic information, etc. Figure 6 As shown in the figure, the application market adds the basic information of the application card when configuring the basic information of the application. The basic information of the card includes: whether the application needs to apply for a card form and the card security level. The developer selects the basic information configuration of the card that best suits the application. During the application listing process, the application market comprehensively considers the application type and the card security level to review the card security level and finally determines the card security level.

[0162] When the developer's application is officially submitted to the application market, the application will be changed to "listed" after the application market reviewer passes the review, and the user can search and download the corresponding development in the application market. During the application download and installation process, the terminal device can also obtain the card security level of the application that supports the card display form. The subsequent card rendering is processed according to the security level.

[0163] In one embodiment of a possible implementation of the card security level division, the card security level configurations of different applications are preset in the terminal device. Through the package name or application name corresponding to the application pre-set in the terminal, the application obtained and installed by the user through the application market or other means, the corresponding card security level in the preset configuration is clarified, and the subsequent card rendering is processed according to the security level. In one embodiment of a possible implementation of the card security level division, the card security level configurations of different applications are preset in the terminal device. The preset configuration can be updated when the device is connected to the Internet, and can also be modified and updated by the user.

[0164] Cards display important information in the form of cards on the desktop or other applications. Users can use cards through quick gestures, achieve direct access to services through lightweight interactive behaviors, and reduce the purpose of level jump. The core concept of cards is to provide users with easy-to-use and clear information content, integrate intelligent capabilities into the card experience for users to choose to use, and meet the display and adaptation requirements on different devices.

[0165] In the embodiment of the present application, the card user can be a system application such as a desktop, a Dock bar, etc., or a non-system application, and no specific limitation is made here.

[0166] Exemplarily, the electronic device may install one or more applications. Some or all of the applications installed in the electronic device may provide service cards. In one possible implementation, the terminal device may pre-install some service cards when it leaves the factory. In one possible implementation, the terminal device recommends a corresponding service card to the user based on the user portrait. In one possible implementation, the user adds the service cards provided by one or some of the applications to the desktop according to his or her needs.

[0167] A possible way to add cards is introduced. Users can add cards directly through the application icon on the desktop. For example, the user performs corresponding interactive operations on the application icon for which the card is to be generated, such as long pressing. After long pressing, a list of options pops up. Click the service card option in the pop-up list to enter the card adding interface, and click the Add to Desktop button. The corresponding card will be generated in the blank area of ​​the desktop. In a possible implementation, the user can directly perform desktop interactive operations such as long pressing in the blank area of ​​the desktop where the card is to be displayed. After long pressing, a list of options pops up. Click the service card option in the pop-up list to enter the card adding interface, select the card for which the application service is to be added, and click the Add to Desktop button. The corresponding card will be generated in the blank area of ​​the desktop.

[0168] Users add cards through the service card center page. For example, the electronic device displays the desktop, and the user can slide on the side or bottom area of ​​the electronic device (or slide up the edge or other user interaction operations), and the electronic device presents the service card center page. The service card center page presents the cards that the user has used / collected or recommended for the user, and the user can select the cards he is interested in and add them directly to the desktop.

[0169] Users can add cards through the application market. For example, the entrance of the card service market in the application market, the user can click to enter the service card application market, and select the service card they want in the card market to add to the desktop.

[0170] If the user is not satisfied with the location of the card, he can edit it again. For example, he can press and hold the card and drag it to the desired location.

[0171] If the user is not satisfied with the display effect of the card on the desktop, they can also perform secondary editing. For example, they can long press the card to call out other styles corresponding to the card, and then choose the style they like. Users can also customize the design of the card style.

[0172] If the user is not satisfied with the card size, they can also perform secondary editing. For example, they can pinch and zoom the card size to adjust it to a size that the user is satisfied with.

[0173] The card user involved in the embodiment of the present application is the host application that displays the card content and controls the location where the card is displayed in the device. The card user is responsible for the management and control of the entire life cycle of the card. When adding a card, the card user adds the card corresponding to the application. When deleting a card, the card user needs to notify the death of the card. When the card user enters the foreground, the card can be updated by identifying the enable refresh status mark. The card user can be a system application, such as the desktop, negative one screen, drop-down menu, slide-up menu, sidebar application, service center, etc., or it can be other third-party applications, such as weather, audio and video applications.

[0174] like Figure 7 As shown, the card management service (Form Manager Service, FMS) involved in the embodiment of the present application is used to manage the resident proxy service of the cards added to the system, including the publication, management, use and periodic refresh of card objects. At the same time, the card management service is responsible for card cache management. When a card is added to the card management service, the card management service caches the view information of the card so that the cached data can be directly returned the next time the card is acquired to reduce latency. The card management service is responsible for card life cycle management. When the card is switched to the background or blocked, the card refresh is suspended; when the card is upgraded or uninstalled, the card data is updated and cleaned up. The card management service is responsible for card user object management, manages the inter-process communication (Inter-Process Communication, IPC) of the card user, and is used for verification of user requests and callback processing after the card is updated. The card management service continues to pay attention to the death notification of the card user, and cleans up the user's remote objects when receiving the death notification of the card user.

[0175] like Figure 8 As shown, the card provider involved in the embodiment of the present application is an application that provides card display content, controls the display content of the card, the control layout of the card, and the interactive events on the card, etc. The card provider developer implements the card provider embodiment management module, which is responsible for the persistent management of the cards allocated by the card management service. The card provider process is pulled up through the broadcast mechanism. The process can be an independent process or the main process of the application. After processing the card business, it can become a cache process. The card provider developer implements the interface of the extension service to implement the corresponding card services for requesting to create cards, update cards, and delete cards. The card provider includes not only system applications preset when the terminal device leaves the factory, such as clock / settings, but also non-system applications installed later, such as weather / NetEase Cloud, etc. The card provider can also be embedded in the same application, that is, this application is both a card provider and a card user.

[0176] The card rendering service (Form Rendering Service, FRS) involved in this embodiment is a card rendering process independent of the host process, responsible for the rendering of all added cards and the management and control of card rendering instances. The card rendering service involved in the embodiment of the present application is used to manage card rendering instances, and the rendering instances are bound one by one to the cards on the card user. The card rendering service runs the card page code for rendering and sends the rendered data to the card corresponding to the card user.

[0177] like Fig. 9 As shown, the principle of common card rendering is demonstrated. The card provider needs to create a new card and sends a card creation request to the card management service through its communication adaptation layer. The request carries card-related information, such as the card name, specifications, layout, and update policy. After the card management server receives the card creation request, the card cache management module caches the acquired card data. When the card user starts, it will register with the card management service, and through continuous reception, it will determine that the current card request is to create a card, and send a card rendering request to the card rendering service through the communication adaptation layer. The card rendering service completes the drawing and rendering of the current card and manages the rendering instance at the same time. After the card rendering service is completed, the card user object management module of the card management service manages the new card user object and notifies the card provider that the card has been successfully added.

[0178] The common card refresh implementation principle is basically the same as the card creation principle mentioned above, except that the card refresh request sent by the card provider needs to carry the card refresh data. After the card user finds the card refresh request, he updates the request to card refresh, and the card rendering service completes the card refresh.

[0179] like Fig.10 In the illustrated embodiment, two or more independent card rendering service processes are used to complete the rendering service of all cards in the device.

[0180] The card rendering process is the card display process. Specifically, the host application of the terminal device obtains the card file, and the host's application engine (AppEngine) obtains the system capabilities of the current terminal device, and then runs the card to complete the card rendering process. The card management service maintains the mapping relationship between the rendering process and the host process. When a card needs to be rendered, the corresponding process is assigned for rendering according to the card's security level. Cards of the same security level are rendered in the same process. After the card management service obtains the card security level, it determines whether the current device already has an independent card rendering process corresponding to the security level. If so, continue to use the surviving (running / sleeping) independent card rendering service process of this type of card security level for rendering; otherwise, create a new independent card rendering service process as the rendering process for cards of this type of security level.

[0181] like Fig.10 As shown, the independent card rendering service process FRS1 is responsible for rendering the implementation examples of all Class 1 cards, and the independent card rendering service process FRS2 is responsible for rendering the implementation examples of all Class 2 cards. Different processes operate in different sandboxes. At this time, card application rendering services of different security levels are implemented through different independent rendering processes, so that applications of different security levels can perform their own card rendering in different sandboxes through process isolation. The isolation of resource status data of cards of different security levels is achieved through process isolation, which is relatively Fig. 9 The virtual machine isolation of different application cards in the sandbox has a higher security level. Even if the malicious code breaks into the virtual machine, the independent rendering process FRS1 running in different sandboxes cannot affect the independent rendering process FRS2 running in other sandboxes.

[0182] When the security level of a card is divided into only two categories, two independent card rendering service processes are used for rendering, and each independent card rendering service process is responsible for rendering cards of one security level; when the security level of a card is classified into N categories greater than two categories, N independent card rendering service processes can be used to render N categories of application cards respectively, and cards of the same security level are rendered by the same independent card rendering service process.

[0183] Fig.11 The implementation process of this embodiment is described in detail. The card provider inherits the card service from the developer to implement requests such as creating cards, updating cards, and deleting cards, and provides corresponding card services. The cards of the provider application are divided into two categories according to any classification strategy. The cards of high-security applications are one type of cards, which have higher demands for the security of the data resource operating environment. The cards of other non-high-security ordinary applications are the second type of cards. Card display A, card display B, card display C, and card display D are the card displays corresponding to card provider application A, card provider application B, card provider application C, and card provider application D respectively. Card display A, card display B, card display C, and card display D can be displayed on the same card user application or on different card user applications. The card provider application, card management service, card rendering service, and card user application communicate through their respective communication adaptation layers.

[0184] like Fig.11As shown, when card provider A sends a request to start card rendering, the card management service receives the request and determines the security level of card A to identify it as a Class I card. The card management service determines that the current device does not have a Class I card rendering service process, so the card management service creates a new independent rendering service process FRS1 to complete the card rendering service for Class I card rendering A. When card provider B sends a request to start card rendering, the card management service receives the request and determines the security level of card B to identify it as a Class I card. The card management service determines that the current device has a Class I card rendering service process FRS1, so the card management service continues to use the independent rendering service process FRS1 to complete the card rendering service for Class I card rendering B.

[0185] like Fig.11 As shown, when card provider C sends a request to start card rendering, after receiving the request, the card management service determines the security level of card C and clarifies that it is a Class II card. The card management service determines that the current device does not have a Class II card rendering service process, so the card management service creates a new independent rendering service process FRS2 to complete the card rendering service for Class II card C. When card provider D sends a request to start card rendering, after receiving the request, the card management service determines the security level of card D and clarifies that it is a Class II card. The card management service determines that the current device has a Class II card rendering service process FRS2, so the card management service continues to use the independent rendering service process FRS2 to complete the card rendering service for Class II card D.

[0186] The first-class card rendering service FRS1 and the second-class card rendering service FRS2 are both independent card rendering service processes, and the two processes run in two different sandboxes. Through process isolation, the data resource status between application cards of different security levels is completely isolated and independent of each other. After the card rendering service FRS1 completes the rendering, the content of the first-class card display A and the first-class card display B are displayed on the corresponding card user. After the card rendering service FRS2 completes the rendering, the content of the second-class card display C and the second-class card display D are displayed on the corresponding card user.

[0187] In one possible implementation of the above-described embodiment, a card rendering service management module is provided to uniformly manage and allocate card rendering services. After starting card rendering, the card management service directly sends a rendering request to the card rendering service management through the communication adaptation layer. The card rendering service management module determines the security level of the currently requested card and then matches it to the corresponding card rendering process for card rendering.

[0188] In the above-described embodiment, in another possible implementation, the first-class card provider A and the first-class card provider B can be the same high-security application, and the rendering of different cards in the same application also uses the card rendering process of the corresponding security level to render the card. The second-class card provider application C and the second-class card provider application D can also be the same ordinary application.

[0189] like Fig.12 In another embodiment shown, since a class of cards has the highest security level requirement, different provider applications may use different independent card rendering processes to render cards of the same class of cards with the same security level.

[0190] The card management service maintains the mapping relationship between the rendering process and the host process. When the card needs to be rendered, the corresponding process is assigned for rendering according to the security level of the card. For the first-class cards with the highest security level, due to their highest security requirements, different independent card rendering processes are used for rendering for different card providers. After the card management service obtains the card security level, it determines whether the card security level is a first-class card displayed by a high-security application. If not, the card is rendered in the same manner as the above embodiment. If it is a first-class card, it is determined whether the current device already has an independent card rendering process corresponding to the card provider application. If so, continue to use the independent card rendering service process of the surviving (running / sleeping) card provider application for rendering; otherwise, create a new independent card rendering service process as the rendering process for the card provider application security level card.

[0191] like Fig.12 As shown, both card A and card B are display cards corresponding to the high-security application with the highest security level. In sandbox 1, the rendering service of a class of card A is completed by an independent card rendering service process FRS1, and the content is displayed on the corresponding user's class of card display A. In sandbox 2, the rendering service of a class of card B is completed by an independent card rendering service process FRS2, and the content is displayed on the corresponding user's class of card display B. A class of cards are rendered separately using different rendering processes due to different card provider applications. The highest security level card application rendering service is implemented through different independent rendering processes, so that high-security applications perform their own card rendering in different sandboxes. Relative to Fig.10The rendering method in the sandbox process isolation method is used to isolate the resource status data of different application cards in high-security applications. For non-high-security card provider applications, the independent card rendering service process FRS3 is responsible for the rendering of all implementation examples of the second type of cards. At the same time, the rendering process and the card form a mapping relationship, so that the corresponding process can be found when the above-mentioned card needs to be rendered again later. Different applications create different rendering processes and render them separately, thereby achieving the goal that applications with the same card security level do not have the authority to read each other's data.

[0192] When the security level of a card is classified into N categories greater than two, for the card with the highest security requirement level, different card providers use different independent rendering service processes for rendering. For cards of other security levels, N-1 independent card rendering service processes can be used for rendering respectively, and cards of the same security level are rendered using the same independent card rendering service process.

[0193] Fig.13 The implementation process of this embodiment is described in detail. The card provider inherits the card service from the developer to implement requests such as creating cards, updating cards, and deleting cards, and provides corresponding card services. The cards of the provider application are divided into two categories according to any classification strategy. The cards of high-security applications are one type of cards, which have higher demands for the security of the data resource operating environment. The cards of other non-high-security ordinary applications are the second type of cards. Card display A, card display B, card display C, and card display D are the card displays corresponding to card provider application A, card provider application B, card provider application C, and card provider application D respectively. Card display A, card display B, card display C, and card display D can be displayed on the same card user application or on different card user applications. The card provider application, card management service, card rendering service, and card user application communicate through their respective communication adaptation layers.

[0194] like Fig.13 As shown, when card provider A sends a request to start card rendering, the card management service receives the request and determines the security level of card A to identify it as a Class I card. The card management service determines that the current device does not have a rendering service process for Class I card A, so the card management service creates a new independent rendering service process FRS1 to complete the card rendering service for Class I card A. When card provider B sends a request to start card rendering, the card management service receives the request and determines the security level of card B to identify it as a Class I card. The card management service determines that the current device does not have a rendering service process for Class I card B, so the card management service creates a new independent rendering service process FRS2 to complete the card rendering service for Class I card B.

[0195] like Fig.13As shown, when card provider C sends a request to start card rendering, after receiving the request, the card management service determines the security level of card C and clarifies that it is a Class II card. The card management service determines that the current device does not have a Class II card rendering service process, so the card management service creates a new independent rendering service process FRS3 to complete the card rendering service for Class II card C. When card provider D sends a request to start card rendering, after receiving the request, the card management service determines the security level of card D and clarifies that it is a Class II card. The card management service determines that the current device has a Class II card rendering service process FRS2, so the card management service continues to use the independent rendering service process FRS3 to complete the card rendering service for Class II card D.

[0196] Different processes will run in different sandboxes. Class A card rendering service FRS1 and Class B card rendering service FRS2 are both independent card rendering service processes. Different process renderings are performed in different sandboxes, so the two processes run in two different sandboxes. Sandbox isolation is achieved through process isolation, ensuring the complete isolation and mutual independence of data resource states between applications with different security levels of Class A cards. After the card rendering service FRS1 completes rendering, Class A card display A is displayed on the corresponding card user. After the card rendering service FRS2 completes rendering, Class A card display B is displayed on the corresponding card user. After the card rendering service FRS3 completes rendering, the content of Class B card display C and Class B card display D is displayed on the corresponding card user.

[0197] In one possible implementation of the above-described embodiment, a card rendering service management module is provided to uniformly manage and allocate card rendering services. After starting card rendering, the card management service directly sends a rendering request to the card rendering service management through the communication adaptation layer. The card rendering service management module determines the security level of the currently requested card and then matches it to the corresponding card rendering process for card rendering.

[0198] In the above-mentioned embodiment, in another possible implementation, the first-class card provider A and the first-class card provider B are different high-security applications, and the second-class card provider application C and the second-class card provider application D can be the same common application.

[0199] For example, Fig.14 FIG. 1 is a flow chart of another embodiment. Fig.14 As shown, the method includes S801-804.

[0200] S801. The card provides a request to send a card display.

[0201] The card display request is to start card rendering. In some embodiments, the provider data may have changed and the display data needs to be refreshed, so the display request is sent. It may also be the first time that the provider application loads the display card and needs to add a card, so the display request is sent.

[0202] S802: Identify and display the security level of the card.

[0203] The terminal device identifies the security level of the card displayed by the card provider application. The specific card security level identification can be directly determined by the card management service module, or a card rendering service management module can be added to the device to determine the security level of the card to be displayed.

[0204] S803. Cards with the same card security level are rendered using the same independent card rendering service process.

[0205] The card management service determines the security level of the card to be displayed in S802. If an independent card rendering service process with the same security level already exists, the process is used to continue rendering the card to be displayed. If an independent card rendering service process with the same security level does not exist, the card management service creates a new independent card rendering service process to render the card. The card management service stores the matching relationship between the card to be rendered and the independent card rendering service process.

[0206] In another possible implementation, a card rendering service management module may be added to the device, and the card rendering service management module is used to uniformly manage all card rendering service processes. Step S803 may be completed entirely by the card rendering service management module.

[0207] S804: The card user displays the rendered card.

[0208] Data from different card providers can be displayed on the same card user or on different card users. Different cards from the same card provider can be displayed on the same card user or on different card users. After the independent card rendering service process completes the rendering of the card to be displayed, it is displayed on the corresponding card user. The card displayed on the card user shows the data of the card provider, and the displayed card can also support some common user interaction operations.

[0209] For example, Fig.15 FIG. 1 is a flow chart of another embodiment. Fig.15 As shown, the method includes S901-904.

[0210] S901. The card provides a request to send a card display.

[0211] For specific implementation, please refer to S801.

[0212] S902: Identify and display the security level of the card.

[0213] For specific implementation, please refer to S802.

[0214] S903. For a type of card, cards from different card providers are rendered by different independent card rendering service processes; for the remaining cards, cards with the same security level are rendered by the same independent card rendering service process.

[0215] The card management service determines the security level of the card to be displayed in S902. If the security level of the card to be displayed is the highest class I card, if there is already an independent card rendering service process corresponding to the card provider, the process will be used to continue rendering the card to be displayed. If there is no independent card rendering service process corresponding to the card provider, the card management service will create a new independent card rendering service process to render the card corresponding to the card provider. If the card to be displayed is other non-class I security levels, refer to S803 to render the card. The card management service stores the matching relationship between the card to be rendered and the independent card rendering service process.

[0216] In another possible implementation, a card rendering service management module may be added to the device, and the card rendering service management module is used to uniformly manage all card rendering service processes. Step S903 may be completed entirely by the card rendering service management module.

[0217] S904: The card user displays the rendered card.

[0218] For specific implementation, please refer to S804.

[0219] In the present invention, animation rendering and UI thread are separated, animation acts on the rendering node, one control corresponds to one rendering node, and the animation of the control is the animation generated for each frame by modifying the rendering node properties. There are some high-power or special animations in the controls on the card interface. Therefore, in a possible implementation method, when different rendering processes are used for rendering according to the security level of the card, the cards with the same security level are rendered using the same rendering process, which can further limit the rendering permissions of different rendering processes. The higher the security level of the card rendering process, the higher the rendering permissions, that is, the more animation properties can be set for each card control rendering node. The control animation properties that the operating system can provide are divided as shown in Table 4. The properties of appearance, position size, radiation change and filter that each control has are collectively referred to as general animatable properties. The content drawing property animation unique to a single control is called a custom drawing property. Cards with different security levels have different permissions for setting control animation properties.

[0220]

[0221] Table 4 Control animation

[0222] Different animation features can be generated by setting the animation properties of the control, such as panning animation, transparent animation, looping animation, etc. The setting of some animation properties of the control will have a relatively large impact on the card display and device power consumption. For example, the setting of the transparency of the control needs to be strictly controlled. Therefore, some animation properties of the control are only open to cards with higher security levels.

[0223] Exemplarily, the card security level is divided into two categories. The second category of cards is common ordinary cards that support general card capabilities, such as data display, data refresh, page jump, etc. The first category of cards can set the location, size, filter, and partial appearance (rounded corners, border color, border line width, background color, shadow) of the control. The rendering process corresponding to the second category of cards renders the corresponding control according to the settings at the rendering node of the corresponding control during rendering. The first category of cards is the card with the highest security level and has some more complex card capabilities, such as direct control of applications. The first category of cards also has the ability to render some special animation properties that the second category of cards does not have, such as looping animation and transparency properties. Looping animations bring greater power consumption to the device, so the rendering process corresponding to the first category of cards can render looping animations. The first category of cards can also set the transparency property of the card control. The corresponding rendering process can render implicit animations through the setting of this property to display invisible transparent cards.

[0224] When the user wants to delete a card, the deletion of the card can also be triggered through certain interactive methods. When all the cards corresponding to the independent card rendering service process are deleted by the user, the independent card rendering service process will die and the resources occupied by the process will be released.

[0225] For memory management, the maximum number of rendering processes can be limited. When the number of rendering processes opened by the device reaches a preset upper limit, the terminal device can release resources according to a certain release strategy. For example, a resource release strategy that the terminal device can adopt is to give priority to releasing the card rendering process in the background. The so-called background cards are cards that are not displayed in the foreground.

[0226] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, a data center, etc. that contains one or more available media integration. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk), etc.

[0227] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.

Claims

1. A card rendering method, applied to an electronic device, characterized in that: The method comprises: receiving a first operation of creating a first card, wherein the security level of the first card is a first security level; Drawing the first card using a first rendering process according to the security level of the first card; receiving a second operation of creating a second card, wherein the security level of the second card is a second security level; According to the security level of the second card, the second card is drawn using a second rendering process, wherein the first rendering process and the second rendering process are different; and the first card and the second card are displayed.

2. The method according to claim 1, characterized in that: The method further comprises: The electronic device obtains the security level of the first card from a server.

3. The method according to claim 1, characterized in that The method further comprises: Obtain the first correspondence between the application and the card security level; The security level of the first card is determined according to the first corresponding relationship.

4. The method according to claim 1, characterized in that: The method further comprises: Acquire a second correspondence between an application set and an application category, wherein the first card data comes from a first application, and the first application belongs to the application set; Acquire a third correspondence between the application classification and the card security level; An application category of the first application is determined according to the second corresponding relationship, and a security level of the first card is determined according to the application category of the first application and the third corresponding relationship.

5. The method according to claim 4, characterized in that The method further comprises: The second card data comes from a second application; An application classification of the second application is determined according to the second corresponding relationship, and a security level of the second card is determined according to the application classification of the second application and the third corresponding relationship, wherein the security level of the second card is different from the security level of the first card.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: receiving a third operation of creating a third card, wherein the security level of the third card is the first security level; Drawing the third card using a third rendering process, wherein the third rendering process is different from the first rendering process; The third card is displayed.

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: The first rendering process has a rendering capability of special animations; The second rendering process does not have the rendering capability of the special animation, wherein the special animation includes a transparent animation or a looping animation.

8. An electronic device, characterized in that: The electronic device comprises: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code comprises computer instructions, and the one or more processors call the computer instructions so that the electronic device executes the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on an electronic device, the electronic device is caused to execute the method as claimed in any one of claims 1 to 7.

10. A computer program product comprising computer readable instructions which, when executed by one or more processors, implement the method of any one of claims 1 to 7.

Images