Widget management method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a widget management method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a code binding package of a target widget based on a resource link of the target widget in response to an adding instruction of the target widget; during cross-process running, generating a rendering data packet of the widget content of the target widget based on the code binding packet of the target widget; and sending the rendering data packet to a desktop starter of the electronic equipment, so that the desktop starter associates the rendering data packet with a container corresponding to the target widget on a desktop, and a widget content interface of the target widget is displayed through the container. According to the embodiment of the invention, the dependence on the existing application can be reduced, and the widget can be formed without depending on whether the APP exists or not, so that the widget can be conveniently and flexibly obtained.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a widget management method, apparatus, electronic device and storage medium. Background Technology

[0002] Currently, in mobile application systems, widgets (also known as small components) are installed on mobile devices along with the application (app). For example, a weather widget depends on a weather app, and a clock widget depends on a clock app. These can be called native widgets, meaning that a widget's code needs to be compiled and packaged together with the corresponding app before it can be installed on the electronic device and found in the device's widget list. Widgets are generated from the app, similar to a parasitic relationship, lacking the application path of generating the widget first and then calling the app's data. Furthermore, some older app versions do not support widgets; only newer versions of the app support them. This forces users to install a new app or update an existing app when they want to use a new widget, or they can only rely on the widget format provided by the developer, making it difficult to create highly customized widgets or widgets that meet specific functions based on user preferences. Summary of the Invention

[0003] This application provides a widget management method, apparatus, electronic device, and storage medium, which can reduce dependence on existing applications and form widgets without depending on the existence of the APP, thereby making it convenient and flexible to obtain widgets.

[0004] In a first aspect, embodiments of this application provide a widget management method applied to the widget backend of an electronic device. Each widget managed by the widget backend does not require a pre-set corresponding foreground activity page. The method includes: In response to the add command for the target widget, the code bundle of the target widget is obtained based on the resource link of the target widget; During cross-process runtime, a rendering data package of the widget content of the target widget is generated based on the code bundle of the target widget; The rendering data packet is sent to the desktop launcher of the electronic device, so that the desktop launcher associates the rendering data packet with the container corresponding to the target widget on the desktop, so as to display the widget content interface of the target widget through the container.

[0005] Secondly, embodiments of this application provide a widget management device applied to the widget backend of an electronic device. Each widget managed by the widget backend does not require a pre-set corresponding foreground activity page. The device includes: The acquisition module is used to, in response to the add instruction of the target widget, acquire the code bundle of the target widget based on the resource link of the target widget; The generation module is used to generate a rendering data package of the widget content of the target widget based on the code bundle of the target widget during cross-process runtime. The sending module is used to send the rendering data packet to the desktop launcher of the electronic device, so that the desktop launcher associates the rendering data packet with the container corresponding to the target widget on the desktop, so as to display the widget content interface of the target widget through the container.

[0006] Thirdly, embodiments of this application provide an electronic device, including: a display module, a network interface, a processor, and a memory. The network interface, the processor, and the memory are connected. The display module is used to display an interface. The network interface is used to provide data communication functions. The memory is used to store a computer program. The processor is used to call the computer program to execute the method described in the first aspect.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including program instructions that are executed by a processor to perform the method described in the first aspect.

[0008] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a computer processor, implements the method described in the first aspect.

[0009] In this embodiment, the electronic device has a widget backend installed. Widgets do not require a pre-installed foreground activity page; instead, a widget backend manages all widgets on the electronic device. In response to an add command for a target widget, the widget backend obtains the target widget's code bundle based on the target widget's resource link, for example, by downloading the code bundle from a server using the resource link. During cross-process execution, such as from the widget backend process to the desktop process (desktop launcher), the widget backend generates a rendering data package of the target widget's content based on the target widget's code bundle and sends the rendering data package to the electronic device's desktop launcher. This allows the desktop launcher to associate the rendering data package with the container corresponding to the target widget on the desktop, displaying the target widget's content interface through the container. Therefore, this application achieves dynamic widget distribution through code bundles, reducing reliance on existing applications. It allows for convenient and flexible widget acquisition, forming widgets regardless of the app's existence, thus saving storage space on the electronic device and improving the user's widget acquisition experience. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. Other drawings can be obtained based on these drawings without creative work.

[0011] Figure 1 This is a schematic diagram of the structure of a widget management system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a widget management method provided in an embodiment of this application; Figure 3a This is a schematic diagram of a dynamic widget distribution process provided in an embodiment of this application; Figure 3b This is a flowchart illustrating a widget application permission process provided in an embodiment of this application; Figure 3c This is a schematic diagram of a widget acquiring data according to an embodiment of this application; Figure 4 This is a flowchart illustrating another widget management method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a widget management device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained based on the embodiments of this application without creative work are within the scope of protection of this application.

[0013] Please see Figure 1 This is a schematic diagram of the architecture of a widget management system provided in an embodiment of this application. The widget management system includes a terminal 101, a service platform 102, and an electronic device 103, wherein: The service platform 102 can be directly or indirectly connected to the terminal 101 and electronic device 103 through wired or wireless communication, and this application does not impose any restrictions on this.

[0014] Service platform 102 can function as an artificial intelligence (AI) platform, providing widget generation services. For example, it can receive user-defined widget generation instructions, parse these instructions, and generate a code bundle or its resource link (such as a download address) corresponding to the AI ​​widget. Service platform 102 can store the generated code bundles for each widget, which can then be downloaded and used by electronic device 103. For instance, service platform 102 can send the resource link of the AI ​​widget to electronic device 103, which can then download the corresponding AI widget's code bundle based on the resource link.

[0015] Terminal 101 allows users to input custom widget generation instructions and submit them to service platform 102. The widget generation instructions include descriptions of the widget's function and appearance.

[0016] Electronic device 103 can receive the resource link of the widget issued by service platform 102, download the code bundle of the widget from service platform 102 according to the resource link, and use the code bundle to transmit the corresponding widget package across processes.

[0017] In one embodiment, the electronic device 103 can also allow the user to input custom widget generation instructions and submit the widget generation instructions to the service platform 102. After the service platform 102 generates the corresponding widget code bundle, it sends the resource link to the electronic device 103. The electronic device 103 downloads the widget code bundle from the service platform 102 according to the resource link, and uses the code bundle to transmit the corresponding widget package across processes, thereby providing the user with the corresponding widget service. Cross-process means that a connection can be established between the app, launcher, and widget of the electronic device, so that the widget can obtain the app's data.

[0018] For example, when a user needs a personalized clock widget, they can send a widget generation instruction to the service platform 102 via terminal 101 or electronic device 103. The widget generation instruction includes the user's description of the clock widget's functional and aesthetic requirements. The service platform 102 then generates a corresponding AI clock widget code bundle and resource link based on AI technology. Electronic device 103 uses the resource link to obtain the AI ​​clock widget code bundle and installs the AI ​​clock widget, thus providing the user with a personalized clock widget service.

[0019] In one embodiment, when an add instruction for a target widget (such as the AI ​​widget mentioned above) is received, the widget backend of the electronic device 103 responds to the add instruction by obtaining the code bundle (e.g., a bundle package) of the target widget from the service platform 102 based on the resource link of the target widget. During cross-process runtime, the widget backend generates a rendering data package of the widget content of the target widget based on the code bundle of the target widget, and sends the rendering data package to the desktop launcher of the electronic device. The desktop launcher associates the rendering data package with the container corresponding to the target widget on the desktop to display the widget content interface of the target widget through the container. It can be seen that, in this embodiment, when a user needs to add a new widget, the code bundle of the new widget is obtained through dynamic delivery technology. Using the code bundle, widgets can be obtained conveniently and flexibly, thereby reducing dependence on existing applications and forming widgets without depending on the existence of the app, thus improving the user's widget acquisition experience.

[0020] Furthermore, by establishing a cross-process remote rendering channel, decoupled rendering between the desktop launcher and widgets is achieved. Specifically, the widget background is responsible for rendering the widget's content interface, while the desktop launcher is responsible for displaying the widget's content interface. For AI widgets, since they are usually unapproved and their security is unknown, if the Remote Views solution in related technologies is adopted, the rendering and updating of AI widgets are all handled by the Launcher's main thread. If an AI widget malfunctions, it may cause the desktop to crash or freeze, seriously affecting the normal use of electronic devices. Through the embodiments of this application, even if an AI widget malfunctions, since the widget process (i.e., the widget background) is responsible for rendering its own widget content interface, and the desktop is only responsible for displaying the AI ​​widget's content interface, the desktop launcher and widgets are decoupled in rendering. The malfunction of the AI ​​widget will not affect the normal operation of the desktop, and will not cause the desktop to restart or crash. Thus, through the effective isolation between widgets and the desktop, the stable operation of the desktop can be guaranteed.

[0021] After widgets are created, the decoupling between the launcher and the custom widgets prevents them from directly initiating data requests through the launcher. Instead, they need to obtain permissions from the corresponding app based on the specific custom widget. This means that when a widget does not have a pre-defined foreground activity page, it needs to find a solution to request app permissions.

[0022] At this point, a widget backend is needed to build the data request path between custom widgets and the app, allowing widgets to request permissions and access app data normally even without a pre-built foreground activity page. These widgets can be custom widgets, such as AI widgets, or widgets with specific functions.

[0023] In one embodiment, AI-generated widgets do not rely on third-party applications. For example, weather widgets generated by AI do not depend on corresponding weather apps. The widget process of AI widgets can be uniformly implemented by a pre-built widget backend (also known as the widget host process). That is, the widget backend can uniformly manage the operation of all AI widgets and distinguish different widgets by widget ID. When users add new widgets, they do not need to download related applications or upgrade application versions, which helps to save storage space on electronic devices.

[0024] In one embodiment, since AI widgets are typically unapproved, to ensure their secure operation on the desktop and maintain a good user experience, a blacklist or whitelist can be maintained based on user ratings for each widget. For example, widgets with high user ratings can be added to the whitelist and pushed to the electronic device, allowing users to select widgets from the whitelist to add to their desktop. Alternatively, widgets with low user ratings or serious security vulnerabilities can be added to the blacklist. If a user selects a widget that is on the blacklist, the user should be prompted to be cautious about adding it or refuse to receive the code bundle.

[0025] Specifically, the terminal 101 and electronic device 103 can be smartphones, tablets, laptops, desktop computers, smart terminals mounted on mobile platforms, wearable devices, etc., but this application embodiment does not limit them.

[0026] It should be noted that, Figure 1 The number of terminals 101, service platform 102, and electronic devices 103 shown are merely illustrative and can be flexibly adjusted according to actual needs. Service platform 102 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers.

[0027] The implementation details of the technical solutions in the embodiments of this application are described in detail below: Please see Figure 2 This is a flowchart illustrating a widget management method provided in an embodiment of this application. This widget management method can be applied to... Figure 1 The electronic device 103 in the system runs a widget background. The widget management method may specifically include the following steps: 201. In response to the add instruction of the target widget, obtain the code bundle of the target widget based on the resource link of the target widget.

[0028] The target widget is an AI widget generated by an AI platform based on user-defined commands. The widget backend is a background app, invisible to the user; it can be understood as a hidden system app. The widget backend manages the various AI widgets installed on the electronic device; these AI widgets do not require pre-installed foreground activity pages.

[0029] Specifically, users can select the target widget to add from the widget list provided by the service platform. The widget backend responds to the add command for the target widget, obtains the resource link of the target widget, and downloads the code bundle of the target widget from the service platform based on the resource link.

[0030] In one embodiment, the code bundle may specifically be a bundle package.

[0031] 202. During cross-process execution, a rendering data package of the widget content of the target widget is generated based on the code bundle of the target widget.

[0032] Specifically, after the widget backend receives the code bundle of the target widget, in order to enable the cross-process execution of the code bundle on the electronic device, the widget backend can generate a rendering data package of the widget content of the target widget based on the code bundle of the target widget. Through the conversion from code bundle to rendering data package, efficient and accurate rendering of AI widgets can be achieved.

[0033] In one embodiment, the rendering data package can be a Surface Package.

[0034] In one embodiment, the widget backend can utilize React Native technology to generate rendering data packages, which may specifically include: The storage path of the target widget's code bundle is passed to the React Instance Manager. The React Instance Manager processes the code bundle to generate a React Root View, and then generates a rendering data package containing the widget's content based on the React Root View. As can be seen, processing based on the React Native framework can accurately and efficiently reconstruct the code bundle into a rendering data package containing the corresponding widget's content, thereby enabling dynamic deployment of AI widgets and reducing reliance on existing apps.

[0035] In one embodiment, such as Figure 3a The diagram shown is a flowchart illustrating a dynamic distribution of widgets according to an embodiment of this application.

[0036] Specifically, the process involves the widget's background process downloading a bundle from the service platform based on the target widget's resource link and storing it in the device's local storage. Then, the bundle's storage path (path) is passed to the React Instance Manager. The React Instance Manager retrieves the bundle based on the path and renders it, generating a React Root View. The React Instance Manager then passes the React Root View to the Surface Package Manager, which converts the React Root View into a data stream called SurfacePackage. Finally, the SurfacePackage is sent to the Launcher via Inter-Process Communication (IPC), which can utilize the Android Interface Definition Language (AIDL). This establishes a cross-process rendering channel between the widget's background process and the desktop process, achieving decoupled rendering between the launcher and the widget.

[0037] Since the widget backend does not require a pre-built foreground Activity, when building the React InstanceManager, you need to set Require Activity to false to prevent runtime errors. Specifically, you can do this: React Instance Manager.set Require Activity(false). Then, you can build an Android View (i.e., React Root View) through the React InstanceManager, and then convert it into a SurfacePackage to be sent to the launcher.

[0038] 203. Send the rendering data packet to the desktop launcher of the electronic device, so that the desktop launcher associates the rendering data packet with the container corresponding to the target widget on the desktop, so as to display the widget content interface of the target widget through the container.

[0039] Specifically, the widget backend sends the rendered data packet to the desktop launcher via IPC communication. The desktop launcher receives the rendered data packet of the target widget, determines the container corresponding to the target widget that needs to be associated based on the widget ID of the target widget, and associates the rendered data packet with the container, thereby establishing a cross-process remote drawing channel. The widget content interface of the target widget can be displayed through this container.

[0040] In one embodiment, the container can be a Surface View instance.

[0041] In this embodiment, when an add instruction for a target widget (such as the AI ​​widget mentioned above) is received, the widget backend of the electronic device responds to the add instruction by obtaining the code bundle (e.g., a bundle package) of the target widget from the service platform based on the resource link of the target widget. During cross-process runtime, the widget backend generates a rendering data package of the widget content of the target widget based on the code bundle of the target widget, and sends the rendering data package to the desktop launcher of the electronic device. The desktop launcher associates the rendering data package with the container corresponding to the target widget on the desktop to display the widget content interface of the target widget through the container. Therefore, this embodiment obtains the code bundle of the new widget through dynamic delivery technology when the user needs to add a new widget. Using the code bundle allows for convenient and flexible widget acquisition, thereby reducing dependence on existing applications and enabling widgets to be formed without relying on the existence of the app, thus improving the user's widget acquisition experience.

[0042] Furthermore, in this embodiment, the widget backend is responsible for rendering the widget content interface, while the desktop launcher is responsible for displaying the widget content interface. By establishing a cross-process remote drawing channel, decoupled rendering between the desktop launcher and the widget is achieved. Even if the AI ​​widget malfunctions, since the widget backend is responsible for rendering its own widget content interface and the desktop is only responsible for displaying the AI ​​widget's widget content interface, the malfunction of the AI ​​widget will not affect the normal operation of the desktop, nor will it cause the desktop to restart or crash. Thus, through the effective isolation between the widget and the desktop, the stable operation of the desktop can be guaranteed.

[0043] Please see Figure 4 This is a flowchart illustrating another widget management method provided in an embodiment of this application. This widget management method can be applied to... Figure 1 The electronic device 103 in the system runs a widget background. The widget management method may specifically include the following steps: 401. In response to the add instruction of the target widget, obtain the code bundle of the target widget based on the resource link of the target widget.

[0044] 402. During cross-process execution, a rendering data package of the widget content of the target widget is generated based on the code bundle of the target widget.

[0045] 403. Send the rendering data packet to the desktop launcher of the electronic device, so that the desktop launcher associates the rendering data packet with the container corresponding to the target widget on the desktop, so as to display the widget content interface of the target widget through the container.

[0046] The specific implementation of steps 401-403 can be found in the relevant description of steps 201-203 in the aforementioned embodiments, and will not be repeated here.

[0047] 404. Obtain the first permission request of the target widget, wherein the first permission request is obtained by intercepting the second permission request initiated by the code bundle of the target widget during the running process and rewriting the second permission request.

[0048] Specifically, when a target widget needs to access / call certain hardware and software resources of an electronic device (such as photos, contacts, calendar, camera, etc.), it cannot effectively initiate the corresponding permission request because it lacks a corresponding pre-built foreground Activity. To address this, when a second permission request is detected initiated by the target widget's code bundle during runtime, the request is intercepted and sent to the operating system. The resulting first permission request is then rewritten; for example, the transmission path of the ReactPermission data packet in the second permission request can be rewritten. Permission requests from various widgets are then uniformly transferred to the widget's backend for processing. For instance, the widget's backend might construct the permission request path between the target widget and related apps.

[0049] In one embodiment, the permissions requested by the first permission request include any one of the following: photo album, recording, contacts, camera, location, and other applications.

[0050] In one embodiment, when multiple widgets initiate permission requests, the widget backend determines the processing order of these widgets and responds to each widget's permission request according to this order. For example, the widget backend can obtain the priority or importance level of each widget to the user and determine the processing order based on this priority or importance level. Alternatively, the processing order can be determined based on the time sequence of the permission requests, e.g., earlier requests are processed first. Following these rules ensures the accurate determination of the widget request processing order and guarantees the effective execution of widget permission requests.

[0051] In one embodiment, different widgets typically have different refresh frequencies. For example, a daily updated photo album widget (low frequency), a time widget (high frequency, refreshes every minute), a weather widget (refreshes every hour), a step count widget (refreshes when exercising, not when not exercising), and a music widget (refreshes when music is playing, not when not playing music). In this case, priority can be determined based on refresh frequency, or refresh requirements can be determined in real-time based on application operation (e.g., whether music is being played), with widgets requiring refresh having higher priority. If only one widget permission request can be processed at a time, the widget refresh priority can be determined by combining user status and / or device status. For example, the step count widget has higher priority than other widgets when the user is running; similarly, the time widget has higher priority than other widgets when the electronic device is unlocked, and so on. Alternatively, it can be set to handle two or more widget permission requests at a time to prevent situations where both the time and weather widgets need to refresh simultaneously, resulting in one widget not refreshing in time and being perceived as not refreshing by the user, thus affecting the user's widget experience. This establishes a reasonable and efficient permission request path between widgets and the app.

[0052] Alternatively, the widget backend can determine the maximum concurrency based on the remaining resource information of the electronic device, and process the permission requests of multiple target widgets in parallel according to the maximum concurrency to improve the efficiency of permission requests.

[0053] 405. In response to the first permission request, launch the first foreground activity page and send the first permission request to the operating system through the first foreground activity page.

[0054] The widget backend has the ability to launch a foreground activity page for authorization. By launching the foreground activity page, it effectively sends a permission request to the operating system, causing the operating system to display an authorization confirmation foreground activity page on the desktop interface (such as an authorization prompt pop-up). Users can authorize or deny authorization to the target widget by clicking yes / no.

[0055] In one embodiment, the widget backend can be set in the privileged directory of the operating system. Specifically, the privileged directory can be a high-privilege folder system_ext / priv-app, which gives the widget backend high privileges, including the ability to directly launch the foreground activity page in the background without user intervention (such as clicking, long-pressing, etc.).

[0056] Specifically, the foreground activity page corresponding to the authorization prompt pop-up requires another foreground activity page to be launched, but widgets do not have a pre-built foreground activity page. The widget backend launches a first foreground activity page (which can be called the permission request foreground activity page) to process the first permission request. This first foreground activity page can then send the first permission request to the operating system. The operating system can display this first permission request by launching a foreground activity page (such as an authorization prompt pop-up), for example, when the target widget requests access to the photo album. The authorization prompt pop-up can include the widget's identifier, obtain the user's confirmation of the first permission request, i.e., whether the user allows the target widget to access the relevant resources, and obtain the permission request result.

[0057] In one embodiment, since the first front-end activity page is only used as a temporary proxy for permission requests and does not need to display data or interact with the user, and making the first front-end activity page visible to the user would affect the normal display of content on the desktop interface, the first front-end activity page can be set to a transparent front-end activity page.

[0058] 406. Obtain the permission request result returned by the operating system, and send the permission request result to the code bundle of the target widget.

[0059] Specifically, the widget backend receives the permission request result returned by the authorization prompt pop-up of the operating system through the first front-end activity page, and sends the permission request result to the code bundle of the target widget to inform the target widget of the permission request result, so that the target widget can perform the next operation, such as requesting relevant data.

[0060] In one embodiment, when the first foreground activity page is set to a transparent foreground activity page, since the first foreground activity page may still receive user touch events, its view hierarchy can be set to be lower than the desktop interface's view hierarchy so that the first foreground activity page does not receive user touch events; or, when the first foreground activity page receives a user touch event, the received touch event can be blocked, that is, the first foreground activity page does not respond to the received touch event. By setting the view hierarchy or blocking touch events, the normal use of the desktop can be effectively avoided due to starting a transparent foreground activity page, thus ensuring the smooth interactive capabilities of the desktop interface.

[0061] In addition, after obtaining the permission request result returned by the operating system, the widget backend can destroy the first foreground activity page to avoid the resource occupation caused by the first foreground activity page existing for a long time and affecting the desktop user experience. That is, the foreground activity page launched by the widget backend only needs to be saved briefly during use and destroyed after use.

[0062] In one embodiment, the widget backend can manage the operation of multiple widgets, each of which can be identified by a widget ID. After obtaining the permission request result of the target widget returned by the operating system, the widget backend obtains the widget identifier of the target widget and, based on the widget identifier, sends the permission request result to the code bundle of the target widget, so that the target widget can be informed of the permission request result in a timely manner.

[0063] In one embodiment, such as Figure 3b The diagram shown is a flowchart illustrating a widget permission application process provided in an embodiment of this application.

[0064] Specifically, this can include: Widgets initiating permission requests via React Permissions data packets, such as requesting contact, calendar, or camera permissions. By intercepting and modifying React Permissions data packets, permission requests are uniformly forwarded to the Widget's backend Application. The Application then launches a transparent permission request foreground activity, the Permission Activity, to send permission requests to the operating system. The Permission Activity can trigger the operating system to display an authorization prompt pop-up foreground activity. The Permission Activity obtains the user's authorization result—whether the permission request is allowed—and sends the user's authorization result back to the React Permissions data packet, allowing Widgets to be promptly informed of the permission request result.

[0065] 407. If the permission application result is successful, obtain the first data request of the target widget. The first data request is obtained by intercepting the second data request initiated by the code bundle of the target widget during the operation and rewriting the second data request.

[0066] Specifically, when a target widget needs to access data from an electronic device (such as photos, contacts, calendar, etc.), it cannot effectively initiate the corresponding data request because it lacks a corresponding pre-built foreground Activity. In this case, if the permission request is approved (meaning the user allows the target widget to use the relevant resources), the target widget's code bundle can initiate a second data request. When a second data request initiated by the target widget's code bundle during runtime is detected, the widget's backend intercepts this second data request sent to the operating system and rewrites the first data request resulting from the second data request. For example, it can rewrite the data packet transmission path of the second data request, uniformly transferring data request requests from various widgets to the widget's backend for processing. For instance, the widget's backend constructs the data request path between the target widget and the relevant app.

[0067] In one embodiment, when multiple widgets initiate data requests, the widget backend determines the processing order of these widgets and responds to each widget's data request according to this order. For example, the widget backend can obtain the priority or importance level of each widget to the user and determine the processing order based on this priority or importance level. Alternatively, the processing order can be determined based on the time sequence of the data requests, e.g., earlier requests are processed first. Following these rules ensures the accurate determination of the widget request processing order and guarantees the effective execution of widget data requests.

[0068] In one embodiment, different widgets typically have different refresh frequencies. For example, a daily updated photo album widget (low frequency), a time widget (high frequency, refreshes every minute), a weather widget (refreshes every hour), a step count widget (refreshes when exercising, not when not exercising), and a music widget (refreshes when music is playing, not when not playing). In this case, priority can be determined based on refresh frequency, or refresh needs can be determined in real-time based on application operation (e.g., whether music is being played), with widgets requiring refresh having higher priority. If only one widget data request can be processed at a time, the widget refresh priority can be determined by combining user status and / or device status. For example, the step count widget has higher priority than other widgets when the user is running; similarly, the time widget has higher priority than other widgets when the electronic device is unlocked, and so on. Alternatively, it can be set to process two or more widget data request requests at a time to prevent situations where the time widget and weather widget need to refresh simultaneously, resulting in one widget not refreshing in time and being perceived as not refreshing by the user, thus affecting the user's widget experience. This establishes a reasonable and efficient data request path between widgets and the app.

[0069] Alternatively, the widget backend can determine the maximum concurrency based on the remaining resource information of the electronic device, and process the data requests of multiple target widgets in parallel according to the maximum concurrency to improve the efficiency of data request.

[0070] 408. In response to the first data request, launch a second foreground activity page, and send the first data request to the operating system through the second foreground activity page to launch a data selection page, wherein the data selection page is used to select data that the target widget is allowed to use.

[0071] Among them, the widget backend has the authorization capability to launch a foreground activity page from the background. By launching the foreground activity page, it effectively sends a data request request from the widget to the operating system, so that the operating system displays the corresponding data selection page (which is also a foreground activity page) on the desktop interface. The user selects the data that the target widget is allowed to use through the data selection page.

[0072] Specifically, the data selection page requires another foreground activity page to launch, but the target widget does not have a corresponding pre-set foreground activity page. The widget's backend launches a second foreground activity page (which can be called a data processing foreground activity page) to transfer the first data request to the second foreground activity page for processing. The second foreground activity page can then send the first data request to the operating system. The operating system can launch the corresponding data selection page. For example, if the requested data is a photo album, the photo album data selection page will be launched. The user selects the target data that the target widget is allowed to use through the data selection page and confirms the request. In other words, the widget's backend triggers the system to launch the data selection foreground activity page by launching a foreground activity page.

[0073] In one embodiment, since the second front-end activity page is only used as a temporary proxy for data requests and does not need to display data or interact with the user, and making the second front-end activity page visible to the user would affect the normal content display of the desktop interface, the second front-end activity page can be set to a transparent front-end activity page.

[0074] In one embodiment, the target widget backend can receive the target data selected by the user through the data selection page via the second front-end activity page, and then send the target data to the code bundle of the target widget through the React instance manager, so that the target widget can quickly obtain the required target data and execute the corresponding widget logic, such as image display, calendar display, etc.

[0075] In one embodiment, when the second foreground activity page is set as a transparent foreground activity page, since the second foreground activity page may still receive user touch events, its view hierarchy can be set to be lower than the desktop interface's view hierarchy so that the second foreground activity page will not receive user touch events; or, when the second foreground activity page receives a user touch event, the received touch event can be blocked, that is, the second foreground activity page does not respond to the received touch event. By setting the view hierarchy or blocking touch events, the normal use of the desktop can be effectively avoided due to starting a transparent foreground activity page, thus ensuring the smooth interactive capabilities of the desktop interface.

[0076] In addition, after obtaining the target data returned by the data selection page, the widget backend can destroy the second foreground activity page to avoid resource occupation caused by the second foreground activity page existing for a long time and affecting the desktop user experience. That is, the foreground activity page launched by the widget backend only needs to be saved briefly during use and destroyed after use.

[0077] In one embodiment, such as Figure 3c The diagram shown is a schematic flowchart of a widget acquiring data according to an embodiment of this application.

[0078] Specifically, this can include: After the widget's code bundle is granted permission, it initiates a data request via a bridge package, such as requesting contact data, photo data, or calendar data. The React instance manager of the code bundle intercepts and modifies (or significantly alters) the widget's request packet, causing the data request to be uniformly forwarded to the widget's backend Application. The Application then launches a transparent data processing foreground activity, the Data Handle Activity, to send a data request to the operating system. For example, the Data Handle Activity uses `start For Result` to request the operating system to launch the corresponding Activity (i.e., the data selection page). For instance, if requesting photo data, the operating system will launch the photo selection Activity; if requesting contact data, the operating system will launch the contact selection Activity. After the user selects data in the corresponding Activity, they return the selected data to the Data Handle Activity via `set Result`. The Data Handle Activity then returns the selected data to the React instance manager, which in turn returns the selected data to the widget's code bundle via a bridge channel, enabling the widget to obtain the requested data promptly and accurately.

[0079] This application embodiment effectively solves the permission request and data acquisition problems that arise during the process of loading widgets through the widget background and displaying them on the desktop via a cross-process transmission pipeline when dynamically distributing AI widgets. By placing the widget background in a privileged directory, its permissions are enhanced, allowing it to directly launch the foreground activity page from the background. Furthermore, by intercepting permission or data requests initiated by the widget's code bundle, all widget requests are transferred to the widget background for intermediary processing. The widget background completes permission or data requests by directly launching the foreground activity page in the background. This enables accurate and efficient dynamic generation of widgets without the need for a pre-installed foreground activity page, and effectively establishes a data request path between the widget and the app through the widget background. This allows the widget to normally request permissions and access app data even without a pre-installed foreground activity page, thus providing a complete and smooth widget user experience.

[0080] Please see Figure 5 This is a schematic diagram of a widget management device according to an embodiment of this application. The device is applied to the widget backend of an electronic device. Each widget managed by the widget backend does not need to have a corresponding foreground activity page pre-set. The device includes: The acquisition module 501 is used to, in response to the addition instruction of the target widget, acquire the code bundle of the target widget based on the resource link of the target widget; Processing module 502 is used to generate a rendering data package of the widget content of the target widget based on the code bundle of the target widget during cross-process runtime. The sending module 503 is used to send the rendering data packet to the desktop launcher of the electronic device, so that the desktop launcher associates the rendering data packet with the container corresponding to the target widget on the desktop, so as to display the widget content interface of the target widget through the container.

[0081] In one embodiment, the processing module 502 is specifically used for: Pass the storage path of the code bundle of the target widget to the React instance manager; The React instance manager is invoked to process the code bundle of the target widget and generate the React root view; A rendering data package for the widget content of the target widget is generated based on the React root view.

[0082] In one embodiment, the acquisition module 501 is further configured to acquire a first permission request of the target widget, wherein the first permission request is obtained by intercepting a second permission request initiated by the code bundle of the target widget during runtime and rewriting the second permission request. The processing module 502 is further configured to launch the first front-end activity page in response to the first permission request; The sending module 503 is further configured to send the first permission request to the operating system through the first foreground activity page; The acquisition module 501 is also used to acquire the permission request result returned by the operating system; The sending module 503 is also used to send the permission request result to the code bundle of the target widget.

[0083] In one embodiment, the first front-end activity page is a transparent front-end activity page.

[0084] In one embodiment, the processing module 502 is further configured to: Set the view hierarchy of the first foreground activity page to be lower than the view hierarchy of the desktop interface; or, block touch events received by the first foreground activity page. Delete the first front-end activity page.

[0085] In one embodiment, the sending module 503 is specifically used for: Obtain the component identifier of the target component; Based on the widget identifier of the target widget, the permission request result is sent to the code bundle of the target widget.

[0086] In one embodiment, the permissions requested by the first permission request include any one of the following: photo album, recording, contacts, and other applications.

[0087] In one embodiment, the processing module 502 is further configured to: When there are multiple target widgets initiating permission requests, determine the processing order of the multiple target widgets; Respond to the permission request request corresponding to each of the target widgets in the processing order described above.

[0088] In one embodiment, the widget backend has the authorization capability to launch the foreground activity page from the backend. The acquisition module 501 is further configured to acquire the first data request of the target widget when the permission application result is passed. The first data request is obtained by intercepting the second data request initiated by the code bundle of the target widget during the running process and rewriting the second data request. The processing module 502 is further configured to launch a second front-end activity page in response to the first data request; The sending module 503 is further configured to send the first data request to the operating system through the second foreground activity page to start a data selection page, wherein the data selection page is used to select data that the target widget is allowed to use.

[0089] In one embodiment, the apparatus further includes a receiving module 504, wherein: The receiving module 504 is used to receive target data selected through the data selection page through the second front-end activity page; The sending module 503 is also used to send the target data to the code bundle of the target widget through the React instance manager.

[0090] In one embodiment, the second front-end activity page is a transparent front-end activity page.

[0091] In one embodiment, the processing module 502 is further configured to: Set the view hierarchy of the second foreground activity page to be lower than that of the desktop interface; or, block touch events received by the second foreground activity page. Destroy the second front-end activity page.

[0092] In one embodiment, the target widget is generated by an artificial intelligence platform by implementing custom instructions provided by the user.

[0093] It should be noted that the functions of each functional module of the widget management device in this application embodiment can be specifically implemented according to the methods in the above method embodiments. The specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here.

[0094] Please see Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. The electronic device includes a power supply module and other structures, and includes a processor 601, a storage device 602, a display module 603, and a network interface 604. The processor 601 can output data such as text, images, and videos through the display module 603, for example, displaying the desktop, widget content interface, authorization pop-up window, data selection page, etc. to the user. The processor 601 can interact with external devices through the network interface 604, for example, sending data to an application server and receiving data sent by the application server.

[0095] The storage device 602 may include volatile memory, such as random-access memory (RAM); the storage device 602 may also include non-volatile memory, such as flash memory, solid-state drive (SSD), etc.; the storage device 602 may also include a combination of the above types of memory. The display module 603 may be a display screen with touch functionality.

[0096] The processor 601 may be a central processing unit (CPU). In one embodiment, the processor 601 may also be a graphics processing unit (GPU). The processor 601 may also be a combination of a CPU and a GPU.

[0097] The storage device 602 is used to store program instructions, and the processor 601 can call the program instructions to perform the following operations: In response to the add command for the target widget, the code bundle of the target widget is obtained based on the resource link of the target widget; During cross-process runtime, a rendering data package of the widget content of the target widget is generated based on the code bundle of the target widget; The rendering data packet is sent to the desktop launcher of the electronic device, so that the desktop launcher associates the rendering data packet with the container corresponding to the target widget on the desktop, so as to display the widget content interface of the target widget through the container.

[0098] In one embodiment, the processor 601 is specifically used for: Pass the storage path of the code bundle of the target widget to the React instance manager; The React instance manager is invoked to process the code bundle of the target widget and generate the React root view; A rendering data package for the widget content of the target widget is generated based on the React root view.

[0099] In one embodiment, the processor 601 is further configured to: The first permission request of the target widget is obtained by intercepting the second permission request initiated by the code bundle of the target widget during the running process and rewriting the second permission request. In response to the first permission request, launch the first front-end activity page; The first permission request is sent to the operating system through the first front-end activity page; Obtain the permission request result returned by the operating system; Send the permission request result to the code bundle of the target widget.

[0100] In one embodiment, the first front-end activity page is a transparent front-end activity page.

[0101] In one embodiment, the processor 601 is further configured to: Set the view hierarchy of the first foreground activity page to be lower than the view hierarchy of the desktop interface; or, block touch events received by the first foreground activity page. Delete the first front-end activity page.

[0102] In one embodiment, the processor 601 is specifically used for: Obtain the component identifier of the target component; Based on the widget identifier of the target widget, the permission request result is sent to the code bundle of the target widget.

[0103] In one embodiment, the permissions requested by the first permission request include any one of the following: photo album, recording, contacts, and other applications.

[0104] In one embodiment, the processor 601 is further configured to: When there are multiple target widgets initiating permission requests, determine the processing order of the multiple target widgets; Respond to the permission request request corresponding to each of the target widgets in the processing order described above.

[0105] In one embodiment, the widget backend has the authorization capability to launch a foreground activity page from the background, and the processor 601 is further configured to: If the permission request is approved, the first data request of the target widget is obtained. The first data request is obtained by intercepting the second data request initiated by the code bundle of the target widget during the operation and rewriting the second data request. In response to the first data request, launch the second front-end activity page; The first data request is sent to the operating system through the second foreground activity page to launch the data selection page, which is used to select the data that the target widget is allowed to use.

[0106] In one embodiment, the processor 601 is further configured to: The target data selected through the data selection page is received via the second front-end activity page; Send the target data to the code bundle of the target widget via the React instance manager.

[0107] In one embodiment, the second front-end activity page is a transparent front-end activity page.

[0108] In one embodiment, the processor 601 is further configured to: Set the view hierarchy of the second foreground activity page to be lower than that of the desktop interface; or, block touch events received by the second foreground activity page. Destroy the second front-end activity page.

[0109] In one embodiment, the target widget is generated by an artificial intelligence platform by implementing custom instructions provided by the user.

[0110] In specific implementations, the processor 601, storage device 602, display module 603, and network interface 604 described in the embodiments of this application can execute the embodiments of this application. Figure 2 or Figure 4 The implementation methods described in the relevant embodiments of the provided method can also be used to execute the embodiments of this application. Figure 5 The implementation methods described in the relevant embodiments of the provided device will not be repeated here.

[0111] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. The technical solutions of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which can be a computer, server, or network device, specifically a processor in the computer device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium may include: a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), and other media capable of storing program code.

[0112] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, it should be understood that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A widget management method, characterized in that, A widget backend applied to electronic devices, wherein each widget managed by the widget backend does not require a pre-set corresponding foreground activity page, the method includes: In response to the add command for the target widget, the code bundle of the target widget is obtained based on the resource link of the target widget; During cross-process runtime, a rendering data package of the widget content of the target widget is generated based on the code bundle of the target widget; The rendering data packet is sent to the desktop launcher of the electronic device, so that the desktop launcher associates the rendering data packet with the container corresponding to the target widget on the desktop, so as to display the widget content interface of the target widget through the container.

2. The method according to claim 1, characterized in that, During cross-process runtime, based on the code bundle of the target widget, a rendering data package for the widget content of the target widget is generated, including: Pass the storage path of the code bundle of the target widget to the React instance manager; The React instance manager is invoked to process the code bundle of the target widget and generate the React root view; A rendering data package for the widget content of the target widget is generated based on the React root view.

3. The method according to claim 1 or 2, characterized in that, The method further includes: The first permission request of the target widget is obtained by intercepting the second permission request initiated by the code bundle of the target widget during the running process and rewriting the second permission request. In response to the first permission request, launch the first front-end activity page; The first permission request is sent to the operating system through the first front-end activity page; Obtain the permission request result returned by the operating system, and send the permission request result to the code bundle of the target widget.

4. The method according to claim 3, characterized in that, The first front-end activity page is a transparent front-end activity page; the method further includes: Set the view hierarchy of the first foreground activity page to be lower than the view hierarchy of the desktop interface; or, block touch events received by the first foreground activity page. Delete the first front-end activity page.

5. The method according to claim 3, characterized in that, Sending the permission request result to the code bundle of the target widget includes: Obtain the component identifier of the target component; Based on the widget identifier of the target widget, the permission request result is sent to the code bundle of the target widget.

6. The method according to claim 3, characterized in that, The first permission request requests permissions including any one of the following: photo album, recording, contacts, and other applications.

7. The method according to claim 3, characterized in that, The method further includes: When there are multiple target widgets initiating permission requests, determine the processing order of the multiple target widgets; Respond to the permission request request corresponding to each of the target widgets in the processing order described above.

8. The method according to claim 3, characterized in that, The widget backend has the authorization capability to launch the foreground activity page from the backend, and the method further includes: If the permission request is approved, the first data request of the target widget is obtained. The first data request is obtained by intercepting the second data request initiated by the code bundle of the target widget during the operation and rewriting the second data request. In response to the first data request, a second foreground activity page is launched, and the first data request is sent to the operating system through the second foreground activity page to launch a data selection page, which is used to select data that the target widget is allowed to use.

9. The method according to claim 8, characterized in that, The method further includes: The target data selected through the data selection page is received via the second front-end activity page; Send the target data to the code bundle of the target widget via the React instance manager.

10. The method according to claim 8 or 9, characterized in that, The second front-end activity page is a transparent front-end activity page; the method further includes: Set the view hierarchy of the second foreground activity page to be lower than that of the desktop interface; or, block touch events received by the second foreground activity page. Destroy the second front-end activity page.

11. The method according to claim 1, characterized in that, The target widget is generated by the user through custom instructions, and the artificial intelligence platform generates it by implementing those custom instructions.

12. A micro-device management device, characterized in that, A widget backend for electronic devices, wherein each widget managed by the widget backend does not require a pre-set corresponding foreground activity page, the device comprising: The acquisition module is used to, in response to the add instruction of the target widget, acquire the code bundle of the target widget based on the resource link of the target widget; The generation module is used to generate a rendering data package of the widget content of the target widget based on the code bundle of the target widget during cross-process runtime. The sending module is used to send the rendering data packet to the desktop launcher of the electronic device, so that the desktop launcher associates the rendering data packet with the container corresponding to the target widget on the desktop, so as to display the widget content interface of the target widget through the container.

13. An electronic device, characterized in that, include: The system includes a network interface, a processor, and a memory, wherein the network interface, the processor, and the memory are connected, the network interface is used to provide data communication functions, the memory is used to store computer programs, and the processor is used to invoke the computer programs to perform the method as described in any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions, which are loaded and executed by one or more processors to perform the method as described in any one of claims 1-11.

Images