Software updating method, electronic equipment, readable storage medium and program product

Abstract

The invention relates to the technical field of electronic equipment, and provides a software updating method, electronic equipment, a readable storage medium and a program product, the method is applied to first electronic equipment, and the method comprises the steps that a software version detection request is sent to cloud equipment, and the software version detection request comprises a first user tag; different first user tags correspond to different user updating intentions; target software versions are received from the cloud device, one software version corresponds to one push user tag, and the target software version is a software version with the push user tag matched with the first user tag; and performing software updating based on the target software version. Therefore, the new software version can be pushed based on different updating intentions of the user, and different updating intentions of different users are met, so that the satisfaction degree of the user is improved, and the use experience of the user is ensured.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of electronic devices, and in particular, to a software updating method, an electronic device, a readable storage medium, and a program product. Background Art

[0002] With the iterative update of electronic device technology and in order to provide a better user device experience, electronic devices usually perform software updates regularly / irregularly. However, currently, most of the software updates are pushed to electronic devices based on the device type, which easily leads to poor user experience. Summary of the invention

[0003] The embodiments of the present application provide a software update method, an electronic device, a readable storage medium, and a program product, which can perform software updates based on the adaptability of the user's update intention, thereby satisfying the different update requirements of different users as much as possible, avoiding user dissatisfaction, and improving the user experience.

[0004] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0005] In a first aspect, a software update method is provided, which is applied to a first electronic device, and the method includes: sending a software version detection request to a cloud device, the software version detection request includes a first user tag, and different first user tags correspond to different user update intentions; receiving a target software version from the cloud device, one software version corresponds to a push user tag, and the target software version is a software version whose push user tag matches the first user tag; and performing a software update based on the target software version.

[0006] In this implementation, based on the different update intentions of users represented by different user tags (i.e., the first user tags), a new software version is adaptively pushed to the electronic device (i.e., the first electronic device), so as to meet the different update intentions of different users, thereby solving the problem that different update requirements of different users cannot be met at the same time, thereby avoiding user dissatisfaction, improving user satisfaction, and ensuring user experience.

[0007] In a possible implementation of the first aspect, the software update method also includes: acquiring user operation data, which is user behavior data corresponding to the software update; digitizing the user operation data to form a user behavior sequence, wherein the user behavior sequence includes a numerical value corresponding to the digitized user operation data; and predicting a user tag based on the user behavior sequence to obtain a first user tag.

[0008] In this implementation, the first electronic device quantifies the user operation data into numerical values ​​through numerical processing, which can facilitate using more intuitive and concrete numerical values ​​as features to measure the user's update intention, and then predict the user tag based on the numerical value, thereby ensuring the accuracy of the user tag prediction.

[0009] In a possible implementation of the first aspect, a user tag is predicted based on a user behavior sequence to obtain a first user tag, including: inputting the user behavior sequence into a user portrait model, and the user portrait model predicts the user tag based on the user behavior sequence, and outputs the first user tag; wherein the user portrait model is obtained by training a model using at least one historical behavior sequence as input and a second user tag associated with at least one historical behavior sequence as a learning target; at least one historical behavior sequence is obtained by numerical processing based on historical user operation data; and the second user tag is determined based on user feedback.

[0010] In this implementation, the first electronic device predicts user tags by using a trained user portrait model, which can improve the accuracy of user tag prediction.

[0011] In a possible implementation of the first aspect, because the historical behavior sequence used to train the user portrait model needs to be associated with a second user tag representing different update intentions, and the second user tag needs to be determined by collecting user feedback, and the feedback that can actually be collected is limited, the historical behavior sequence belongs to a small sample data set. Therefore, the user portrait model can adopt a model suitable for small sample data, specifically a support vector machine model.

[0012] In a possible implementation of the first aspect, the user operation data includes any one or more of the reminder pop-up box operation data corresponding to the software update, the reminder notification operation data, the upgrade homepage operation data, the check update operation data, the update switch operation data, and the early upgrade operation data; wherein, the numerical value corresponding to the reminder pop-up box operation data includes the number of operations in which the user triggers a later update and the number of operations in which the user triggers an immediate update; the numerical value corresponding to the reminder notification operation data includes the number of operations in which the user triggers closing the notification and the number of operations in which the user triggers entering the notification; the numerical value corresponding to the upgrade homepage operation data includes the number of operations in which the user triggers entering the homepage; the numerical value corresponding to the check update operation data includes the number of operations in which the user clicks the Check Update button; the numerical value corresponding to the early upgrade operation data includes the number of operations in which the user clicks the Early Upgrade button; the numerical value corresponding to the update switch operation data includes a first numerical value and a second numerical value, and the first numerical value and the second numerical value represent different switch states.

[0013] In a possible implementation manner of the first aspect, the user behavior sequence is updated as the user operation data changes; the user operation data corresponding to the user behavior sequence is operation data generated within the same software version.

[0014] In this implementation, the user behavior sequence is updated at any time as the user operation data changes, which can ensure that the latest and most accurate first user tag is obtained. Furthermore, using the first user tag to request a new software version can ensure the accuracy of the software version push, and using the first user tag to match the reminder strategy can also ensure the accuracy of the reminder strategy. That is, whether it is based on the first user tag for version push or based on the first user tag for update reminders, it is ensured that the different needs of different users can be met as much as possible to improve the user experience. At the same time, using the operation data generated in the same software version to form a user behavior sequence can avoid the value in the user behavior sequence from increasing indefinitely over time as the user operation increases, thereby avoiding affecting the accuracy of the user tag prediction.

[0015] In a possible implementation of the first aspect, software updating is performed based on a target software version, including: when an automatic update condition is met, automatically running and installing the target software version to complete the software update; when the automatic update condition is not met, determining a target reminder strategy based on a first user tag, and prompting the user to manually perform a software update according to the target reminder strategy; wherein different first user tags correspond to different target reminder strategies, and different target reminder strategies correspond to different reminder frequencies and / or reminder methods; the reminder method includes a display method for displaying update reminder information.

[0016] In this implementation, the first electronic device reminds the user to manually update the software according to the reminder strategy matching the first user tag, thereby meeting the different needs of different users for update reminders, thereby further improving the user experience.

[0017] In a possible implementation of the first aspect, a candidate reminder strategy is pre-stored in the first electronic device; the candidate reminder strategy includes a third user tag; and the target reminder strategy is a candidate reminder strategy whose third user tag matches the first user tag. In this implementation, user tags (i.e., third user tags) representing different update intentions are pre-configured for the candidate reminder strategy, and then the target reminder strategy is determined by matching the user tags, thereby ensuring the accuracy of the target reminder strategy selection.

[0018] In a possible implementation of the first aspect, user update intentions are divided into first intentions, second intentions and third intentions according to the intention strength from high to low; candidate reminder strategies include first strategy, second strategy and third strategy; wherein, the third user tag corresponding to the first strategy represents the first intention; the third user tag corresponding to the second strategy represents the second intention; the third user tag corresponding to the third strategy represents the third intention; determining the target reminder strategy according to the first user tag includes: when the first user tag represents the first intention, using the first strategy as the target reminder strategy; when the first user tag represents the second intention, using the second strategy as the target reminder strategy; when the first user tag represents the third intention, using the third strategy as the target reminder strategy; wherein, the reminder frequency corresponding to the first strategy is higher than the reminder frequency corresponding to the second strategy, and the reminder frequency corresponding to the second strategy is higher than the reminder frequency corresponding to the third strategy.

[0019] In this implementation, users with stronger update intentions are matched with reminder strategies with higher reminder frequencies, while users with lower update intentions are matched with reminder strategies with lower reminder frequencies. In this way, update reminders can be provided on demand for users with different update reminder requirements, ensuring user experience.

[0020] In a second aspect, the present application provides a software update method, which is applied to a cloud device, and the method includes: receiving a software version detection request from a first electronic device, the software version detection request includes a first user tag, and different first user tags correspond to different user update intentions; in response to the software version detection request, if it is determined that a target software version exists, the target software version is pushed to the first electronic device; wherein the software version stored in the cloud device corresponds to the push user tag, and the target software version is a software version whose push user tag matches the first user tag.

[0021] In this implementation, when an electronic device (such as a first electronic device) requests a new software version from a cloud device, the cloud device adaptively pushes the new software version to the electronic device based on different update intentions of users represented by different user tags (i.e., first user tags), so as to meet the different update intentions of different users, thereby solving the problem that different update requirements of different users cannot be met at the same time, thereby avoiding user dissatisfaction, improving user satisfaction, and ensuring user experience. In a possible implementation of the second aspect, the first user tag is predicted using a user portrait model; the software update method also includes: receiving at least one historical behavior sequence from a second electronic device, at least one historical behavior sequence is obtained based on historical user operation data; obtaining a second user tag from the second electronic device, the second user tag is determined based on user feedback; associating at least one historical behavior sequence with the second user tag, taking at least one historical behavior sequence as input and taking the associated second user tag as a learning target for model training to obtain a user portrait model; sending the user portrait model to the first electronic device; wherein the second electronic device includes the first electronic device or the second electronic device does not include the first electronic device.

[0022] In this implementation, a user portrait model is trained through a historical behavior sequence formed by historical user operation data and sent to an electronic device. The electronic device can use the user portrait model to predict the first user label, thereby ensuring the accuracy of the user label prediction.

[0023] In a possible implementation manner of the second aspect, for each historical behavior sequence, the historical user operation data corresponding to the historical behavior sequence is operation data generated in the same software version.

[0024] In this implementation, the historical user operation data corresponding to the historical behavior sequence is limited to operation data generated within the same software version, which can prevent the value in the historical behavior sequence from increasing without limit and affecting the characteristic of the value.

[0025] In a possible implementation of the second aspect, the software update method further includes: performing data cleaning on at least one historical behavior sequence to filter out abnormal historical behavior sequences and invalid historical behavior sequences, thereby improving data quality and model accuracy.

[0026] In a third aspect, the present application provides an electronic device, comprising: one or more processors and a memory, the memory being coupled to the processor; one or more computer program codes being stored in the memory, the computer program codes comprising computer instructions; when the processor executes the computer instructions, the electronic device performs the following steps: sending a software version detection request to a cloud device, the software version detection request comprising a first user tag, different first user tags corresponding to different user update intentions; receiving a target software version from the cloud device, one software version corresponding to a pushed user tag, the target software version being a software version whose pushed user tag matches the first user tag; and performing a software update based on the target software version.

[0027] In a possible implementation of the third aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: obtaining user operation data, which is user behavior data corresponding to the software update; digitizing the user operation data to form a user behavior sequence, which includes a numerical value corresponding to the digitized user operation data; predicting a user tag based on the user behavior sequence to obtain a first user tag.

[0028] In a possible implementation of the third aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: inputting the user behavior sequence into the user portrait model, and the user portrait model predicts the user label based on the user behavior sequence, and outputs a first user label; wherein the user portrait model is obtained by training the model with at least one historical behavior sequence as input and a second user label associated with at least one historical behavior sequence as a learning target; at least one historical behavior sequence is obtained by numerical processing based on historical user operation data; and the second user label is determined based on user feedback.

[0029] In a possible implementation of the third aspect, the user operation data includes any one or more of the reminder pop-up box operation data corresponding to the software update, the reminder notification operation data, the upgrade homepage operation data, the check update operation data, the update switch operation data, and the early upgrade operation data; wherein, the numerical value corresponding to the reminder pop-up box operation data includes the number of operations in which the user triggers a later update and the number of operations in which the user triggers an immediate update; the numerical value corresponding to the reminder notification operation data includes the number of operations in which the user triggers closing the notification and the number of operations in which the user triggers entering the notification; the numerical value corresponding to the upgrade homepage operation data includes the number of operations in which the user triggers entering the homepage; the numerical value corresponding to the check update operation data includes the number of operations in which the user clicks the Check Update button; the numerical value corresponding to the early upgrade operation data includes the number of operations in which the user clicks the Early Upgrade button; the numerical value corresponding to the update switch operation data includes a first numerical value and a second numerical value, and the first numerical value and the second numerical value represent different switch states.

[0030] In a possible implementation of the third aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: updating the user behavior sequence as the user operation data changes; the user operation data corresponding to the user behavior sequence is the operation data generated within the same software version.

[0031] In a possible implementation of the third aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device also performs the following steps: when the automatic update conditions are met, automatically run the installation of the target software version to complete the software update; when the automatic update conditions are not met, determine the target reminder strategy according to the first user tag, and prompt the user to manually update the software according to the target reminder strategy; wherein different first user tags correspond to different target reminder strategies, and different target reminder strategies correspond to different reminder frequencies and / or reminder methods; the reminder method includes a display method for displaying the update reminder information.

[0032] In a possible implementation manner of the third aspect, a candidate reminder strategy is pre-stored in the first electronic device; the candidate reminder strategy includes a third user tag; and the target reminder strategy is a candidate reminder strategy whose third user tag matches the first user tag.

[0033] In a possible implementation of the third aspect, the user update intention is divided into the first intention, the second intention and the third intention according to the intention strength from high to low; the candidate reminder strategies include the first strategy, the second strategy and the third strategy; wherein the third user tag corresponding to the first strategy represents the first intention; the third user tag corresponding to the second strategy represents the second intention; the third user tag corresponding to the third strategy represents the third intention; when the above-mentioned computer instructions are executed by the processor, the electronic device also performs the following steps: when the first user tag represents the first intention, the first strategy is used as the target reminder strategy; when the first user tag represents the second intention, the second strategy is used as the target reminder strategy; when the first user tag represents the third intention, the third strategy is used as the target reminder strategy; wherein the reminder frequency corresponding to the first strategy is higher than the reminder frequency corresponding to the second strategy, and the reminder frequency corresponding to the second strategy is higher than the reminder frequency corresponding to the third strategy.

[0034] In a fourth aspect, the present application provides a cloud device, comprising: one or more processors and a memory, the memory being coupled to the processor; one or more computer program codes being stored in the memory, the computer program codes comprising computer instructions; when the processor executes the computer instructions, the cloud device performs the following steps: receiving a software version detection request from a first electronic device, the software version detection request comprising a first user tag, different first user tags corresponding to different user update intentions; in response to the software version detection request, if it is determined that a target software version exists, pushing the target software version to the first electronic device; wherein the software version stored in the cloud device corresponds to the push user tag, and the target software version is a software version whose push user tag matches the first user tag.

[0035] In a possible implementation of the fourth aspect, the first user tag is predicted using a user portrait model; when the above-mentioned computer instructions are executed by the processor, the cloud device further performs the following steps: receiving at least one historical behavior sequence from a second electronic device, wherein at least one historical behavior sequence is obtained based on historical user operation data; obtaining a second user tag from the second electronic device, wherein the second user tag is determined based on user feedback; associating at least one historical behavior sequence with the second user tag, performing model training with at least one historical behavior sequence as input and the associated second user tag as a learning target, and obtaining a user portrait model; and sending the user portrait model to the first electronic device; wherein the second electronic device includes the first electronic device or the second electronic device does not include the first electronic device.

[0036] In a possible implementation of the fourth aspect, for each historical behavior sequence, the historical user operation data corresponding to the historical behavior sequence is operation data generated within the same software version; when the above-mentioned computer instructions are executed by the processor, the cloud device also performs the following steps: performing data cleaning on at least one historical behavior sequence, and screening out abnormal historical behavior sequences and invalid historical behavior sequences.

[0037] In a fifth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor in an electronic device, the electronic device executes the software update method of the first aspect and any possible implementation thereof. Alternatively, when the computer program is executed by a processor in a cloud device, the cloud device executes the software update method of the second aspect and any possible implementation thereof.

[0038] In a sixth aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the software update method of the first aspect and any possible implementation thereof, and the computer may be the above-mentioned electronic device. Alternatively, when executed on a computer, the computer enables the computer to execute the software update method of the second aspect and any possible implementation thereof, and the computer may be the above-mentioned cloud device.

[0039] In a seventh aspect, an embodiment of the present application provides a chip, the chip including a processor, the processor is used to call a computer program in a memory to execute a software update method as in the first aspect and any possible implementation thereof. Alternatively, the processor is used to call a computer program in a memory to execute a software update method as in the second aspect and any possible implementation thereof.

[0040] It can be understood that the beneficial effects that can be achieved by the electronic device of the third aspect and any possible implementation thereof, the cloud device of the fourth aspect and any possible implementation thereof, the computer-readable storage medium of the fifth aspect, the computer program product of the sixth aspect, and the chip of the seventh aspect can refer to the beneficial effects in the first aspect and any possible implementation thereof, or refer to the beneficial effects in the second aspect and any possible implementation thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 An application scenario diagram of a software update provided in an embodiment of the present application;

[0042] Figure 2 A schematic diagram of an interface of an automatic update switch provided in an embodiment of the present application;

[0043] Figure 3 A schematic diagram of an interface for displaying update reminder information provided in an embodiment of the present application;

[0044] Figure 4 A schematic diagram of a regular reminder scenario provided in an embodiment of the present application;

[0045] Figure 5 A schematic diagram of the structure of a cloud device provided in an embodiment of the present application;

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

[0047] Figure 7 A flowchart of a software update method provided in an embodiment of the present application;

[0048] Figure 8A schematic diagram of a push configuration and version push process provided in an embodiment of the present application;

[0049] Fig. 9 A schematic diagram of an interface of a check update button provided in an embodiment of the present application;

[0050] Fig.10 A schematic diagram of an interface for an upgrade and trial button provided in an embodiment of the present application;

[0051] Fig.11 A schematic diagram of a process for determining a user tag provided in an embodiment of the present application;

[0052] Fig.12 A schematic diagram of a process for training a user portrait model provided in an embodiment of the present application;

[0053] Fig.13 A schematic diagram of another process of training a user portrait model provided in an embodiment of the present application;

[0054] Fig.14 A schematic diagram of a reminder strategy matching process provided in an embodiment of the present application;

[0055] Fig.15 A structural block diagram of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The technical scheme of the embodiment of the present application will be clearly and completely described below in conjunction with the drawings in the embodiment of the present application. Among them, in the description of the embodiment of the present application, the terms used in the following embodiments are only for the purpose of describing a specific embodiment, and are not intended to limit the present application. In addition, in order to facilitate the clear description of the technical scheme of the embodiment of the present application, in the embodiment of the present application, if the words "first", "second" and the like are used to distinguish the same items or similar items with basically the same functions and effects. It can be understood by those skilled in the art that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not limit necessarily different. And, in the description of the embodiment of the present application, unless otherwise specified, the meaning of "multiple" means two or more.

[0057] With the iterative update of electronic device technology, and in order to provide a better user device experience, electronic devices usually perform software updates regularly / irregularly. In some embodiments, software updates may include system software updates, non-system application updates, and updates of other resource data. Among them, system software updates include operating system updates and system application updates. Non-system applications may include downloaded third-party applications. It is understandable that the embodiments of the present application do not impose any restrictions on the type of software updated.

[0058] At present, the software versions that need to be updated by electronic devices (such as operating system versions, system application versions, non-system application versions, etc.) are usually pushed to the electronic devices by the cloud. After the electronic device receives the software version that needs to be updated pushed by the cloud, it runs and installs the pushed software version to complete the software update.

[0059] In some embodiments, the software update may be a software upgrade or a software repair. For example, the software update may specifically be an operating system upgrade or a system application upgrade. In some embodiments, the software update may be a full update or a partial update. For example, a full system function upgrade, a partial system function upgrade, a full system application upgrade, or a partial system application upgrade.

[0060] For example, Figure 1 An application scenario diagram of software update is shown.

[0061] like Figure 1 As shown, the electronic device 100 can communicate with the cloud device 200 through the network. When software update is required, the cloud device 200 can push the software version to be updated to the communicating electronic device 100. Then, after receiving the new software version sent by the cloud device 200, the electronic device 100 can run and install the software version to complete the software update.

[0062] Furthermore, due to the differences in hardware and / or software installed in electronic devices, the software versions that electronic devices can support and run are different, so the existing software version push strategies are mostly based on the device identifier / fixed parameters of the device (such as selecting the electronic device by the last digit of the fixed parameter) for grayscale release.

[0063] For example, if the software version A that needs to be updated does not distinguish between software and hardware, that is, the software version A that needs to be updated can be supported and run in all electronic devices, then the cloud device can push the software version A that needs to be updated to all electronic devices without distinguishing between electronic devices with different software and hardware, that is, push the software version A to the entire network.

[0064] For another example, the software version A that needs to be updated currently only supports running in operating system A. In order to ensure the accuracy of the update and improve the effectiveness of the push, the cloud device can push the software version A that needs to be updated only to the electronic devices equipped with operating system A. In other embodiments, the software version can also be pushed to the corresponding electronic devices through public testing, early release of trial versions (such as early releases), user registration, etc.

[0065] However, the problem with the existing push strategy is that the device identifier / fixed parameters of the device can only be used to reflect the type of electronic device (such as to distinguish electronic devices with different software and hardware). Therefore, it is difficult to align the software version pushed by the device identifier / fixed parameters of the device with the user's actual update intention, which can easily affect the user experience and lead to a poor user experience.

[0066] For example, for users who are unwilling or refuse to update (such as users who refuse to upgrade the system), directly pushing new software versions (such as new operating system versions) to them through device identifiers / fixed parameters of the device may cause user dissatisfaction. In addition, when the type of electronic device held by the user who refuses to update happens to be an electronic device with frequent software updates, new software versions will be frequently pushed to the electronic device held by the user who refuses to update, thereby exacerbating user dissatisfaction.

[0067] For another example, contrary to users who refuse to update, for users who expect / are willing to update (such as users who actively perform system upgrades), if new software versions (such as new operating system versions) are pushed only through device identifiers / fixed parameters of the device, the push frequency for this type of users may be reduced, which may in turn cause user dissatisfaction due to infrequent update pushes.

[0068] Based on this, in order to improve the user experience, the present application embodiment provides a software update method. The software update method can be applied to application scenarios including electronic devices and cloud devices, and can be seen in the above Figure 1 The application scenario shown.

[0069] In the embodiment of the present application, before the cloud device pushes a new software version to the electronic device, the electronic device will first send a user tag to the cloud device. This user tag is predicted based on user behavior data and can reflect the user's update intention. That is, different user tags represent users with different update intentions, which may include active update users (such as active / active upgrade users), ordinary update users (such as ordinary upgrade users) and users who refuse to update (such as users who refuse to upgrade).

[0070] At the same time, the software versions stored on the cloud device side are also configured with corresponding user tags. Then, the cloud device will match the user tags sent by each electronic device with the user tags configured for the software version, so as to determine the software version to be pushed (i.e., the target software version) and complete the push of the software version. In other words, in the embodiment of the present application, the cloud device will only push the software version with matching user tags to the electronic device.

[0071] For example, the user tag corresponding to the software version A stored in the cloud device indicates an active user update. Then, if the user tag uploaded by the electronic device also indicates an active user update, the cloud device will push the software version A to the electronic device. If the user tag uploaded by the electronic device indicates a refusal to update the user, then because the user tag corresponding to the software version A indicates an active user update, the two user tags do not match, and the cloud device will not push the software version A to the electronic device.

[0072] In this way, compared with the existing push strategy based on device identification / fixed parameters of the device and other information for version push, which cannot distinguish the user's update intention, causing user dissatisfaction and affecting the user's usage experience, the embodiment of the present application adaptively pushes new software versions to electronic devices based on the different update intentions of users represented by different user tags, thereby satisfying the different update intentions of different users, thereby solving the problem that different update requirements of different users cannot be met at the same time, thereby avoiding user dissatisfaction, improving user satisfaction, and ensuring user experience.

[0073] Furthermore, in addition to the process of pushing the software version, the software version update also includes update reminders.

[0074] That is, after a new software version is pushed to an electronic device, generally speaking, the electronic device will not automatically run and install the new software version directly, but will decide whether to automatically update based on whether the automatic update conditions are met. If the automatic update conditions are not met, the electronic device will also remind the user to perform a manual update based on the configured reminder policy.

[0075] In some embodiments, the electronic device is provided with an automatic update switch, and the user can operate to turn on the automatic update switch to allow the electronic device to automatically update. In this case, the electronic device can be regarded as meeting the automatic update conditions. Then, after the electronic device receives the new software version pushed by the cloud device, because the user allows the electronic device to automatically update, the electronic device can directly install and run the new software version to complete the software update.

[0076] For example, taking a mobile phone as an example, Figure 2 A schematic diagram of an interface of an automatic update switch is shown.

[0077] See also Figure 2 After the mobile phone is turned on, the main interface 1 may be displayed. In the main interface 1, application icons corresponding to application programs such as clock, calendar, gallery, ... phone, information, etc. may be included. It can be understood that Figure 2 The main interface 1 shown in the figure is only an example in the embodiment of the present application, and does not constitute any limitation on the main interface.

[0078] The mobile phone can respond to the user's touch operation on the "settings" application icon in the main interface 1 to enter the settings and display the settings interface 2. Figure 2 As shown, the setting interface 2 may include a setting option of system update. Then, the mobile phone may display a system update setting interface 3 in response to the user's touch operation on the setting option of system update.

[0079] like Figure 2 As shown, the system update setting interface 3 includes an automatic update control option 4, and the automatic update control option 4 includes an automatic update switch 5. The mobile phone can turn on / off automatic update in response to the user clicking the automatic update switch 5.

[0080] Furthermore, when the automatic update switch 5 is turned on to allow the electronic device to automatically update, the electronic device can automatically run and install the software version to complete the software update after receiving the new software version. When the automatic update switch 5 is turned off to not allow the electronic device to automatically update, the electronic device cannot automatically run and install the software version to complete the software update after receiving the new software version.

[0081] In some embodiments, if the user turns off the automatic update switch 5, the mobile phone can display update reminder information through a pop-up window, notification bar, etc. to remind the user to perform manual update.

[0082] In some embodiments, if the electronic device does not provide an automatic update switch, it is assumed that the user does not allow the electronic device to automatically update. After receiving a new software version, the electronic device may also display update reminder information through a pop-up window, notification bar, etc., also to remind the user to manually update the software.

[0083] For example, taking a mobile phone as an example, Figure 3 A schematic diagram of an interface for displaying update reminder information is shown.

[0084] See also Figure 3As shown in (1), the update reminder information can be displayed in the form of a pop-up box, and the pop-up box includes options such as later, detailed information, and update immediately (i.e., download and install). The user can click the corresponding option based on the actual update needs. For example, when the user currently has no update needs or refuses to upgrade, the user can click the later option. Then, after the mobile phone receives the user's click operation on later, it can respond to the operation to close the pop-up box of the update reminder. For another example, when the user wants to know the detailed information of the updated software version, the user can click the detailed information option. Then, after the mobile phone receives the user's click operation on detailed information, it can respond to the operation to display the detailed information. For another example, when the user is willing to upgrade, the user can click the update immediately (i.e., download and install) option. Then, after the mobile phone receives the user's click operation on update immediately, it can respond to the operation to run and install the new software version to complete the software update.

[0085] See also Figure 3 As shown in (2), the update reminder information can be displayed in the notification bar, and the pop-up box includes an update now option. The user can also perform corresponding operations based on the actual update needs. For example, when the user currently has no update needs or refuses to upgrade, the phone can be triggered to close the update reminder notification by clicking Close or Clear with one click. For another example, when the user wants to know the detailed information of the updated software version, the user can directly click on this notification to trigger the phone to display the detailed information. For another example, when the user is willing to upgrade, the user can click on the Update Now option to trigger the collection and operation to install the new software version to complete the software update.

[0086] Understandably, Figure 2 The interface for turning on / off automatic updates is shown. Figure 3 The reminder method and update reminder information shown are all examples of the embodiments of the present application, and can be configured according to actual needs. The embodiments of the present application do not constitute any limitation on the interface for turning on / off automatic updates, the reminder method, and the update reminder information.

[0087] However, most current reminder strategies are indiscriminate. That is, as long as there is an updateable software version in the electronic device, all electronic devices will follow the same reminder strategy to regularly display reminder information to prompt users to manually update the software.

[0088] For example, Figure 4 A schematic diagram of a regular reminder scenario is shown.

[0089] See also Figure 4 , assuming that the general reminder strategy is to remind once every 30 minutes, then after the user clicks on the later trigger collection close pop-up box, the phone will display the pop-up box again after 30 minutes.

[0090] In other words, traditional reminder strategies do not take user intentions into account, resulting in electronic devices indiscriminately reminding all users to update, which can easily cause user dissatisfaction. For example, users who refuse to update will not only receive push notifications for new software versions, but will also receive frequent update reminders that affect user use, thereby exacerbating user dissatisfaction and reducing user experience. For another example, users who actively update will not only fail to receive push notifications for new software versions in a timely manner, but may also fail to receive update reminders in a timely manner, which can also cause user dissatisfaction and lead to a poor user experience.

[0091] Based on this, in the embodiment of the present application, in addition to adaptively pushing new software versions to different electronic devices based on user tags, different reminder strategies can also be configured, such as different reminder strategies corresponding to different user tags. Then, the electronic device matches the corresponding reminder strategy based on the user tag, and the electronic device reminds the user to manually update the software according to the reminder strategy matching the user tag, thereby further improving the user's experience.

[0092] In some embodiments, the cloud device 200 may be a server or other computer device. The server may be an independent physical server or a server cluster or distributed system composed of multiple physical servers.

[0093] In other embodiments, the cloud device 200 may also be a cloud server that provides cloud computing services, including but not limited to cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, and big data and artificial intelligence platforms.

[0094] It can be understood that the embodiment of the present application does not impose any special restrictions on the specific type of the cloud device 200.

[0095] For example, Figure 5 A schematic diagram of the structure of a cloud device is shown.

[0096] The cloud device 200 may include one or more processors 201, one or more memories 202, a power supply component 203, an interface component 204, etc. The processor 201 may include one or more processing units, and the processor 201 may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0097] In the embodiment of the present application, the processor 201 in the cloud device 200 can perform quality measurement on the quality data reported by the electronic device to determine the quality problems generated. The processor 201 then matches the corresponding release control rules and release warning rules according to the quality problems, and implements automated control and quality warning of releases based on the release control rules and release warning rules.

[0098] The memory 202 can be used to store computer executable program code, which includes instructions. In some embodiments, the memory 202 can be arranged in the processor 201 to store instructions and data. In some embodiments, the memory 202 in the processor 201 can be a cache memory. The memory can store instructions or data that have been used by the processor or are used frequently. If the processor needs to use the instruction or data, it can be directly called from the memory. Repeated access is avoided, the waiting time of the processor is reduced, and the efficiency of the system is improved.

[0099] The power supply component 203 is used to supply power to the cloud device 200. The interface component 204 is used to provide various types of interfaces, such as a network interface for connecting to a network. The interface component 204 may also provide a USB interface for connecting to peripheral devices.

[0100] It is understood that the structure of the cloud device illustrated in the embodiment of the present application does not constitute a specific limitation on the cloud device 200. In other embodiments of the present application, the cloud device 200 may include more or fewer components than shown in the figure, or combine certain components, or split certain 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.

[0101] In some embodiments, the electronic device 100 communicating with the cloud device 200 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, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, a vehicle-mounted device, a smart home device, a smart city device, a car computer, a large-screen device, or an interactive routing device.

[0102] It can be understood that the embodiments of the present application do not impose any special restrictions on the specific type of the electronic device. Devices that can interact with users and collect user behavior data, such as devices that can collect user operation data related to software updates, can be regarded as electronic devices in the embodiments of the present application.

[0103] For example, Figure 6 A structural schematic diagram of an electronic device is shown.

[0104] 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 module 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. Among them, the sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.

[0105] 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.

[0106] 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.

[0107] The processor 110 can generate an operation control signal according to the instruction opcode and the timing signal to complete the control of fetching and executing instructions. Specifically in the embodiment of the present application, after the electronic device 100 receives the software version pushed by the cloud device 200, the processor 110 in the electronic device 100 can run and install the received software version to complete the software update.

[0108] 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.

[0109] Exemplarily, specifically in the embodiments of the present application, the electronic device 100 can communicate with the cloud device 200 through a wireless communication function to receive the software version pushed by the cloud device 200.

[0110] In some embodiments, 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. TM Taking the system as an example, the software structure of the electronic device 100 is exemplified. That is, the layered architecture can divide the software into several layers, each layer has a clear role and division of labor. The layers communicate with each other through software interfaces.

[0111] In some embodiments, Android TM The 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.

[0112] The application layer may include a series of application packages. For example, the application package may include applications such as gallery, calendar, map, WLAN, music, SMS, call, navigation, Bluetooth, video, etc. It is understandable that each application in the application layer can update the application by running and installing a new application version pushed by the cloud device.

[0113] 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. For example, the application framework layer may include a window manager for providing a window management service (WMS), an activity manager for providing an activity management service (AMS), an input manager for providing an input management service (IMS), a resource manager for providing various resources, and a notification manager for providing notification functions. In addition, it may also include a view system that can be used to build applications, a content provider for storing and obtaining data, etc.

[0114] Exemplarily, in an embodiment of the present application, update reminders may be implemented through a notification manager. For example, the notification manager may be used to enable an application to display update reminder information in a status bar.

[0115] The Android runtime consists of the core library and the Android runtime. The Android runtime is responsible for converting source code into machine code. The core library is mainly used to provide basic Java class library functions. The hardware abstraction layer runs in user space, encapsulates the kernel layer driver, and provides a calling interface to the upper layer. The kernel layer is the layer between hardware and software.

[0116] The software update method proposed in the embodiment of the present application will be described in detail below in conjunction with the accompanying drawings. It should be noted that the software update method in the following embodiments can be implemented in electronic devices and cloud devices with the above hardware structure.

[0117] Figure 7 A schematic flow chart of a software update method is shown, including steps S701-S708. Figure 7 The software update method provided in the embodiment of the present application is described.

[0118] like Figure 7As shown, the software update method provided in the embodiment of the present application is mainly divided into three stages, including push configuration, version push and update reminder. Among them, the push configuration stage is implemented on the cloud device side (i.e., the cloud side). The version push stage is implemented by the interaction between the cloud device and the electronic device. The update reminder stage is implemented on the electronic device side (i.e., the terminal side).

[0119] It should be noted that although Figure 7 The steps to be performed in these three stages are numbered. However, in the embodiments of the present application, there is no strict order in which the steps in these three stages are performed. Figure 7 The step numbers in the code do not impose any restrictions on the order in which the steps are executed.

[0120] For example, while the electronic device interacts with the cloud device to execute each step in the version push stage, the electronic device can also synchronously execute each step in the update reminder stage, and the cloud device can also synchronously execute each step in the push configuration stage.

[0121] Hereinafter, the embodiments of the present application will respectively describe the steps in these three stages. First, the steps in the two stages of configuration push and version push will be described.

[0122] S701, the cloud device receives version information, where the version information includes a push user tag.

[0123] When a new software version needs to be released, the first user (such as a developer or publisher) can upload the version information to the cloud device. It is understandable that the version information includes the new software version to be released and other resources required for version update, which depends on the actual update requirements, and the embodiments of the present application do not make any restrictions on this.

[0124] In the embodiment of the present application, the version information also includes a push user tag. That is, in the embodiment of the present application, when the cloud device releases a new software version, it is necessary to add the configuration of the user tag field. In simple terms, the push user tag is the user tag configured by the first user for the software version to be released. Exemplarily, the push user tag may include an active update user, a normal update user, a refused update user, etc.

[0125] In a specific embodiment, the push user label can be represented by characters, etc. Exemplarily, characters 1, 2, and 3 can be used to represent different push user labels. For example, 1 can be used to represent a user who refuses to update, 2 can be used to represent a user who updates normally, and 3 can be used to represent a user who actively updates. For another example, 1 can be used to represent a user who actively updates, 2 can be used to represent a user who updates normally, and 3 can be used to represent a user who refuses to update.

[0126] In the embodiment of the present application, by pushing user tags, the push range of the software version can be limited, and the cloud device can subsequently push the version based on the different update requirements of different users by pushing user tags, thereby improving the user experience. That is to say, when a new software version needs to be released and pushed to the electronic device, in the push configuration stage, the first user can configure different tag push ranges for different software versions according to the version requirements.

[0127] For example, assume that the software version currently required to be released is software version A, and the first user configures the push user tag for software version A as "1" according to the version requirement. Then, it means that the cloud device can only push software version A to the target device, which is the electronic device with the reported push user tag as "1".

[0128] In some embodiments, the version request may be an update requirement or update intention of the second user (the person using the electronic device). In other embodiments, the version request may also include the type of electronic device to which the new software version can be applied and other business requirements, which are not limited in the embodiments of the present application.

[0129] S702, the electronic device sends a software version detection request to the cloud device, and the software version detection request carries a target user tag.

[0130] In the embodiment of the present application, the electronic device triggers the cloud device to push a new software version. In other words, the electronic device (ie, the first electronic device) can periodically send a software version detection request to the cloud device.

[0131] Specifically, the electronic device (ie, the first electronic device) can poll and send a software version detection request to the cloud device. That is, the electronic device triggers the cloud device to perform version detection by sending a software version detection request, thereby requesting the cloud device to detect whether there is a new software version that can be pushed.

[0132] In order to adaptively push new software versions based on user update intentions to ensure user experience, the software version detection request sent by the electronic device also carries a user tag. In other words, when the client side polls the cloud side for a new software version through a software version detection request, a user tag field also needs to be added to the software version detection request.

[0133] For the convenience of distinction, the user tag sent by the electronic device to the cloud device is referred to as the target user tag in the embodiment of the present application. In the embodiment of the present application, the target user tag is also referred to as the first user tag or the reporting user tag.

[0134] The target user tag corresponds to the push user tag, and the target user tag also includes an active update user, a normal update user, a refused update user, etc. In addition, in a specific embodiment, the target user tag can also be represented by characters, etc. For example, characters 1, 2, and 3 are also used as target user tags, and the principle is the same as that of the push user tag, which will not be repeated.

[0135] S703, the cloud device performs version detection in response to the software version detection request.

[0136] After receiving the software version detection request sent by the electronic device, the cloud device can perform version detection (i.e., version search) in response to the software version detection request, and determine whether there is a new software version that needs to be updated through version detection. If there is a new software version, the cloud device executes S704. If there is no new software version, the cloud device executes S706.

[0137] S704, the cloud device performs tag matching.

[0138] When the cloud device determines that there is a new software version in response to the software version detection request sent by the electronic device, the cloud device will directly push the new software version to the electronic device in the traditional way. However, the embodiment of the present application is different from the traditional one in that in the embodiment of the present application, the cloud device also needs to perform tag matching, and determines whether to push the new software version to the electronic device based on the result of the tag matching.

[0139] In the embodiment of the present application, the objects of tag matching are the pushed user tag corresponding to the new software version searched by the cloud device, and the target user tag reported and carried by the electronic device corresponding to the software version detection request.

[0140] Specifically, when the push user tag matches the target user tag, the cloud device executes S705, that is, pushes the new software version to the electronic device. When the push user tag does not match the target user tag, the cloud device executes S706, that is, does not push the new software version to the electronic device.

[0141] S705, the cloud device pushes the new software version to the electronic device.

[0142] When the cloud device determines that there is a new software version and the push user tag configured for the new software version matches the target user tag corresponding to the electronic device, the cloud device pushes the new software version to the electronic device. Subsequently, the electronic device can run and install the new software version based on the update operation of the second user to complete the software update.

[0143] S706, the cloud device does not push new software versions.

[0144] When the cloud device determines that there is no new software version, or determines that there is a new software version but the push user tag configured corresponding to the new software version does not match the target user tag corresponding to the electronic device, the cloud device will not push the new software version to the electronic device.

[0145] For example, assume that the cloud device receives a software version detection request A sent by electronic device A, and receives a software version detection request B sent by electronic device B. At the same time, the software version detection request A carries a target user tag A, and the software version detection request B carries a target user tag B. Then, the cloud device will perform a version detection on electronic device A to determine whether electronic device A has a new software version. At the same time, the cloud device will also perform a version detection on electronic device B to determine whether electronic device B has a new software version.

[0146] Then, if it is determined that there are new software version A and software version C for electronic device A, the cloud device will match the push user tag A corresponding to software version A and the push user tag C corresponding to software version C with the target user tag A carried in the software version detection request A sent by electronic device A.

[0147] At the same time, if it is determined that there are new software version A and software version C for electronic device B, the cloud device will also match the push user tag A corresponding to software version A and the push user tag C corresponding to software version C with the target user tag B carried in the software version detection request B sent by electronic device B.

[0148] Furthermore, if the tag matching determines that the same user tag exists, that is, the tags match, the cloud device pushes the new software version to the electronic device. If the same user tag does not exist, that is, the tags do not match, the cloud device will not push the new software version to the electronic device.

[0149] For example, taking the above electronic device A and electronic device B as examples, it is assumed that the target user label A is "1", indicating an active update user. The target user label B is "3", indicating a user who refuses to update. And the push user label A is "1", indicating an active update user. The push user label C is "2", indicating a normal update user.

[0150] Then, through tag matching, it can be determined that because the push user tag A corresponding to software version A matches the target user tag A corresponding to electronic device A, the cloud device will push software version A to electronic device A. However, because the target user tag B of electronic device B does not match the push user tag A corresponding to software version A or the push user tag C corresponding to software version C, even if electronic device B has new software versions A and C, the cloud device will not push the new software versions A and C to electronic device B.

[0151] In some embodiments, if two or more matching new software versions are determined through tag matching, the cloud device can push the latest software version to the electronic device if cross-version updating is possible. If cross-version updating is not possible, the cloud device pushes all new software versions to the electronic device.

[0152] For example, the target user tag A corresponding to the electronic device A matches not only the push user tag A corresponding to the software version A, but also the push user tag C corresponding to the software version C. Then, in the case where cross-version updating is possible, the cloud device pushes the latest software version (i.e., software version A or software version C) to the electronic device A among software versions A and C. In the case where cross-version updating is not possible, the cloud device pushes all new software versions (i.e., software version A and software version C) to the electronic device.

[0153] In this way, cloud devices can push versions based on the different update requirements of different users through user tags, so as to meet the different update requirements of different users as much as possible and ensure that users with different update requirements have a good user experience.

[0154] For example, for users who actively update their software, push user tags representing active users can be configured for most or even all new software versions, so that new software versions can be pushed to the electronic devices corresponding to active users in a timely manner, thereby meeting the active update needs of active users, improving the satisfaction of active users, and ensuring user experience.

[0155] For another example, for users who refuse to update, except for some necessary software updates (such as necessary system upgrades, system repairs, etc.), a small amount of or even no push user tags representing users who refuse to update can be configured for new software versions. In this way, even if the electronic device corresponding to the user who refuses to update requests the cloud device to push a new software version, the cloud device will not push the new software version to the electronic device, thereby meeting the update refusal needs of users who refuse to update, thereby improving the satisfaction of users who refuse to update and ensuring the user experience.

[0156] For example, Figure 8 A schematic diagram of the process of pushing configuration and version push is shown below. Figure 8 Describes the process of pushing configuration and version push.

[0157] refer to Figure 8 , the cloud device side may include a version release platform and an upgrade service module. The version release platform is used to interact with the first user and receive configuration information related to version release. The upgrade service module is used to interact with the electronic device to implement version push. Figure 8 As shown, the process of pushing configuration and version may include steps S1-S5.

[0158] S1, the version release platform receives the configured version information and pushes user tags.

[0159] S2: The version release platform sends the version information and push user tags to the upgrade service module.

[0160] That is, when a new software version needs to be released, the first user can upload the version information and push the user tag through the interactive interface provided by the version release platform. In this way, the version release platform can receive the version information configured by the first user and the push user tag corresponding to the version information. Then, because the module that interacts with the electronic device is mainly the upgrade service module. Therefore, the version release platform sends the received version information and push user tag to the upgrade service module. It can be understood that the specific implementation of S1 and S2 can refer to the above-mentioned record of S701, the principle is the same, and it will not be repeated here.

[0161] S3, the electronic device triggers the upgrade service module to perform version detection.

[0162] S4, upgrade the service module to perform version detection and tag matching.

[0163] S5, the upgrade service module pushes the new software version to the electronic device.

[0164] The software version detection request sent by the electronic device to the cloud device is received and responded by the upgrade service module. The software version detection request carries a target user tag. That is, the upgrade service module performs version detection in response to the software version detection request sent by the electronic device to determine whether there is a new software version. Then, the upgrade service module will match the push user tag corresponding to the detected new software version with the target user tag reported by the electronic device.

[0165] If the upgrade service module determines through version detection that there is a new software version, and determines through tag matching that the push user tag configured corresponding to the new software version matches the target user tag corresponding to the electronic device, the upgrade service module executes S5 to push the new software version to the electronic device.

[0166] On the contrary, if the upgrade service module determines through version detection that there is no new software version, or determines that there is a new software version but the push user tag configured corresponding to the new software version does not match the target user tag corresponding to the electronic device, the upgrade service module will not push the new software version to the electronic device.

[0167] In this way, the upgrade service module in the cloud device can push versions based on different update requirements of different users through user tags, thereby ensuring that users with different update requirements have a good user experience. It can be understood that the specific implementation of S3-S5 can refer to the above-mentioned S702-S706, the principle is the same, and no further description is given.

[0168] Next, the embodiment of the present application describes the various steps in the update reminder stage.

[0169] S707, the electronic device matches the target reminder strategy according to the target user tag.

[0170] After the electronic device receives the new software version, it first determines whether the automatic update conditions are met. If the electronic device meets the automatic update conditions, the electronic device can directly run and install the new software version to complete the software update without an update reminder. If the electronic device does not meet the automatic update conditions, the electronic device cannot automatically complete the software version update, and the electronic device needs to remind the user to manually update.

[0171] In some embodiments, whether the electronic device meets the automatic update condition can be determined by the state of the automatic update switch. When the state of the automatic update switch is on, it means that the electronic device has the automatic update permission, and it can be determined that the electronic device meets the automatic update condition. When the state of the automatic update switch is off, it means that the electronic device does not have the automatic update permission, and it can be determined that the electronic device does not meet the automatic update condition. Exemplary, the automatic update switch can refer to Figure 2 shown.

[0172] When the electronic device needs to remind the user to perform manual update, the electronic device can determine the corresponding target reminder strategy from multiple candidate reminder strategies according to the target user tag. In a specific embodiment, the one-to-one corresponding reminder strategies can be configured in advance according to the user tags and stored in the electronic device.

[0173] For example, the target user tags include three, corresponding to active update users, common update users and update rejection users. Then, the candidate reminder strategies pre-stored in the electronic device may include three reminder strategies corresponding to active update users, common update users and update rejection users.

[0174] That is to say, each candidate reminder strategy pre-stored in the electronic device also corresponds to a user tag (i.e., the third user tag). In this way, the electronic device can perform strategy matching among the three candidate reminder strategies according to the target user tag and the user tag corresponding to the candidate reminder strategy, so as to determine a candidate reminder strategy as the target reminder strategy.

[0175] For example, assume that the three candidate reminder policies are reminder policy A, reminder policy B, and reminder policy C. Then, the electronic device can match reminder policy A, reminder policy B, and reminder policy C according to the target user tag to determine a candidate reminder policy as the target reminder policy. Assume that reminder policy A corresponds to users who refuse to update. When the target user tag is "3" indicating that the user is a user who refuses to update, the matched target reminder policy is reminder policy A.

[0176] In other embodiments, in addition to the automatic update switch, the electronic device may also provide a night update switch on demand. The state of the night update switch is used to indicate that the time period for automatic updates of the electronic device is night time. For example, when the states of the automatic update switch and the night update switch are both on, it indicates that the electronic device can only automatically perform software updates at night. In some embodiments, the time period corresponding to the night can be set according to actual needs, and the embodiments of the present application do not impose any restrictions on this. For example, taking 24 hours as an example, the night time may specifically be 1 a.m. to 4 a.m.

[0177] S708, the electronic device displays updated reminder information according to the target reminder strategy.

[0178] After the electronic device matches the target reminder strategy, it can display the update reminder information according to the target reminder strategy. In the embodiment of the present application, the update reminder information can be displayed in a pop-up box, a notification bar, etc. Figure 3 As shown, no further details are given. In some embodiments, the difference between different reminder strategies corresponding to different user tags may be different reminder frequencies. Alternatively, the difference between different reminder strategies corresponding to different user tags may be different reminder methods. Alternatively, the difference between different reminder strategies corresponding to different user tags may also be other differences, and other differences may be specifically set according to actual reminder business requirements, and the embodiments of the present application do not impose any limitation on this.

[0179] For example, when different reminder strategies are distinguished by different reminder frequencies, the reminder frequency 1 of the active updating user is higher than the reminder frequency 2 of the ordinary updating user, and the reminder frequency 2 of the ordinary updating user is higher than the reminder frequency 3 of the user who refuses to update. That is, reminder frequency 1>reminder frequency 2>reminder frequency 3.

[0180] For example, when different reminder strategies have different reminder methods, users who actively update can use a more intuitive and obvious reminder method. Users who refuse to update can use a less intrusive and less obvious reminder method. For example, the reminder method corresponding to users who actively update can be a pop-up box that displays the update reminder information, so that users who actively update can intuitively see the update reminder information. The reminder method for users who refuse to update can be to display the update reminder information in the notification bar, so that the purpose of update notification can be achieved without directly interfering with users who refuse to update.

[0181] In addition, ordinary update users can display update reminder information in a pop-up box or in the notification bar. For example, for important / necessary software updates, the update reminder information can be displayed in a pop-up box to remind ordinary update users. For non-important / non-necessary software updates, the update reminder information can be displayed in the notification bar to remind ordinary update users.

[0182] Exemplarily, in a situation where different reminder strategies differ in reminder frequency and reminder method, users who actively update can display update reminder information through a pop-up box at a high frequency. For example, as long as the new software version is not running for installation, the electronic device will remind you once every 5 minutes. Users who refuse to update can display update reminder information through the notification bar at a low frequency. For example, the electronic device only displays the update reminder information once in the notification bar. That is, after receiving the new software version, the electronic device can display the update reminder information in the notification bar. If the user clears / closes the displayed update reminder information in the notification bar, the electronic device will no longer display the update reminder information even if the software update has not been completed.

[0183] It can be seen that by matching different reminder strategies with different user tags to display update reminder information, different users can be distinguished according to their intentions and reminded according to different strategies, so as to meet the different needs of different users and ensure the user experience.

[0184] In some embodiments, the above-mentioned target user tag can be predicted by the collected user behavior data using a trained user portrait model. In the embodiment of the present application, because version push and update reminders are mainly implemented through user tags, the user behavior data collected by the electronic device can be user operation data related to software updates.

[0185] In some embodiments, user behavior data can be obtained through daily record of dot data and log data. It is understandable that the dot data and log data recorded daily by the electronic device include user operation data, so that user operation data related to software update can be screened from the dot data or log data.

[0186] In a specific embodiment, taking operating system upgrade as an example, user operation data may include reminder pop-up operation data, reminder notification operation data, upgrade homepage entry operation data, check update operation data, update switch operation data, advance upgrade operation data (such as upgrade trial operation data), etc. It can be understood that the user operation data included in the user behavior data may be more or less according to actual needs, and the embodiments of the present application do not impose any limitation on this.

[0187] Next, in order to use the user behavior data as a feature to measure the user's update intention, the electronic device further quantifies the user operation data to form a corresponding user behavior sequence. In other words, the electronic device can quantify the user operation data into numerical values, and then form a numerical sequence from the numerical values, so as to use the obtained numerical sequence as the user behavior sequence.

[0188] In a specific embodiment, if the user operation data recorded in the dot data is digitized, the obtained user behavior sequence in the embodiment of the present application can also be called a user dot sequence.

[0189] In the following, the embodiments of the present application will be mainly described using dot data as user behavior data.

[0190] Exemplary, reference Figure 3 As shown, after the electronic device displays the update reminder information through a pop-up box, the operation options provided to the user include later, detailed information, and update immediately (ie, download and install). Among them, the user's click operations on later and update immediately can clearly reflect the user's intention to update. At the same time, whether the user clicks later or clicks to update immediately, there will be corresponding records in the dotting data. Therefore, the electronic device can digitize the number of times the user clicks later based on the records of the dotting data to obtain the corresponding value (such as the number of times the user clicks later). And, digitize the number of times the user clicks to update immediately to obtain the corresponding value (such as the number of times the user clicks to update immediately). In this way, the electronic device can complete the digitization of the reminder pop-up box operation data and obtain the value corresponding to the reminder pop-up box operation data.

[0191] Similarly, using the same quantification method as the reminder pop-up box operation data, the electronic device can also quantify the reminder notification operation data, enter the upgrade homepage operation data, check the update operation data, and upgrade the trial operation data.

[0192] For example, the quantification of the reminder notification operation data may include quantifying the number of times a user triggers to close / delete a notification, and the number of times a user clicks on a notification to trigger entering a notification. The quantification of the enter upgrade homepage operation data may be quantifying the number of times a user enters the upgrade homepage. The quantification of the check update operation data may be quantifying the number of times a user clicks on the check update button. The quantification of the upgrade trial operation data may be the number of times a user clicks on the upgrade trial button.

[0193] For example, Fig. 9 A schematic diagram of an interface of a check update button is shown. Fig.10 The following figure shows the interface diagram of the upgrade trial button. Fig. 9 , enter the software update interface through the system and update interface, and the software update interface includes a check update button 901. Fig.10 , click the three dots in the upper right corner of the software update interface to display the upgrade trial button 1001.

[0194] Understandably, Fig. 9 and Fig.10 This is only an example of an interface for the Check Update button and the Upgrade Try button in the embodiment of the present application. Fig. 9 and Fig.10 There are no restrictions on the interface of the Check for Updates button and the Upgrade to Try button.

[0195] As for the update switch operation data, the state of the update switch can directly reflect the user's update intention. Therefore, for the digitization of the update switch operation data, the electronic device can directly perform numerical mapping according to the switch state. For example, for the automatic update switch, when the state of the automatic update switch is on, it can be mapped to be represented by a numerical value of 1 (i.e., the first numerical value). When the state of the automatic update switch is off, it can be mapped to be represented by a numerical value of 0 (i.e., the second numerical value). Similarly, for the night update switch, when the state of the night update switch is on, it can also be mapped to be represented by a numerical value of 1 (i.e., the first numerical value). When the state of the night update switch is off, it can also be mapped to be represented by a numerical value of 0 (i.e., the second numerical value).

[0196] Then, the electronic device forms a sequence of the numerical values ​​corresponding to all the operation data to form a user dot sequence. The electronic device inputs the formed user dot sequence into a trained user portrait model, and the user portrait model predicts the corresponding user label based on the user dot sequence.

[0197] For example, Fig.11 A schematic diagram of a process for determining a user tag is shown.

[0198] refer to Fig.11For each operation data including reminder pop-up box operation data, reminder notification operation data, upgrade homepage operation data, check and update operation data, update switch operation data, and upgrade trial operation data, the electronic device digitizes the dot data, and the obtained values ​​are 1, 0, 1, 0, 1, 0, 1, 1, 0 respectively. Then, the user dot sequence formed by the electronic device based on the digitized values ​​is {1, 0, 1, 0, 1, 0, 1, 1, 0}. Then, the electronic device inputs the user dot sequence {1, 0, 1, 0, 1, 0, 1, 1, 0} into the trained user portrait model, and the user portrait model predicts the user label based on the user dot sequence {1, 0, 1, 0, 1, 0, 1, 1, 0}, and outputs the target user label (i.e., the first user label).

[0199] In the embodiment of the present application, the user portrait model can be a model for predicting user labels obtained by model training based on a historical behavior sequence formed by historical behavior data. In the embodiment of the present application, historical behavior data refers to historical user behavior data. The training process of the user portrait model is as follows:

[0200] First, the cloud device can obtain the update intentions of different users by pushing questionnaires to electronic devices, thereby obtaining user tags for training user portrait models. For ease of distinction, the user tags used for model training obtained through questionnaires and other methods are referred to as training user tags (i.e., second user tags) in this embodiment of the application.

[0201] Then, for the electronic device that has the intention to provide the user with an update (i.e., the second electronic device), the cloud device further interacts with the electronic device to obtain historical behavior data. For example, the cloud device can interact with the electronic device to obtain historical dot data or historical log data, and the obtained historical dot data or historical log data includes the required historical user operation data related to the software update.

[0202] Next, the cloud device digitizes each historical user operation data to form a historical behavior sequence. Alternatively, the electronic device may digitize the user operation data, and after the electronic device obtains the historical behavior sequence, the electronic device directly uploads the historical behavior sequence to the cloud device.

[0203] Finally, the cloud device uses the historical behavior sequence as the user behavior sequence used for training, and associates the corresponding training user tag with the historical behavior sequence, so that each historical behavior sequence corresponds to a user tag. The cloud device uses the historical behavior sequence as input, and the training user tag corresponding to the historical behavior sequence as the learning target to perform model training (i.e. supervised learning) on ​​the user portrait model. It can be understood that the historical behavior sequence formed by digitizing the historical user operation data recorded by the historical dotting data can also be called a historical dotting sequence in the embodiment of the present application.

[0204] For example, Fig.12 A schematic diagram of the process of training a user portrait model is shown.

[0205] refer to Fig.12 , after the electronic device forms a historical dotting sequence {d1, d2, d3, d4, d5, d6, d7, d8, d9} based on the historical dotting data, it uploads the historical dotting sequence {d1, d2, d3, d4, d5, d6, d7, d8, d9} to the cloud device.

[0206] Among them, d1, d2, d3, d4, d5, d6, d7, d8, and d9 are values ​​obtained by digitizing various historical user operation data. d1, d2, d3, d4, d5, d6, d7, d8, and d9 can be any positive integers, depending on the historical user operation data recorded by the actual historical dot data. The embodiments of the present application do not impose any limitations on this.

[0207] After the cloud device receives the historical dot sequence, it can perform data cleaning on the historical dot sequence to filter out abnormal and invalid data. Then, the cloud device associates the user label, that is, it adds the corresponding user label (i.e., training user label) to the historical dot sequence after data cleaning. Then, the cloud device can use the historical dot sequence with user labels (i.e., training user labels) to perform model training. After the cloud device completes the model training, it sends the trained user portrait model to each electronic device. The electronic device can call the user portrait model to predict the target user label.

[0208] In some embodiments, the user portrait model may adopt any existing model structure. For example, the user portrait model may specifically be a support vector machine (SVM) model, a large language model, and the like.

[0209] For example, taking the SVM model as an example, Fig.13 A schematic diagram of the process of training a user portrait model is shown.

[0210] refer to Fig.13After quantifying the historical dotting data, cleaning the data, and associating the user tags (i.e. associating the training user tags), the historical dotting sequences corresponding to different user tags can be obtained.

[0211] like Fig.13 As shown in the figure, ① indicates the historical dot sequence corresponding to the user who actively updates, ② indicates the historical dot sequence corresponding to the user who normally updates, and ③ indicates the historical dot sequence corresponding to the user who refuses to update. Then, the historical dot sequence corresponding to the user labels such as ①②③ is used to train the SVM model to obtain the trained SVM model, and the trained SVM model is used as the user portrait model. It can be understood that Fig.13 The historical dotting sequences shown in are only some examples in the embodiments of this application. Fig.13 The illustration does not constitute any limitation on the actual historical dotting sequence.

[0212] Exemplary, combined Fig.11 , Fig.14 A schematic diagram of a process of reminder strategy matching is shown.

[0213] refer to Fig.14 After the electronic device obtains the target user tag (i.e., the first user tag) through the output of the user portrait model, the target user tag can be used to further determine the type of user. That is, the electronic device determines whether the user is an active update user, a normal update user, or a user who refuses to update through the target user tag, and then the electronic device matches the corresponding reminder strategy.

[0214] That is to say, user update intention can be divided into positive (i.e., first intention), normal (i.e., second intention) and rejection (i.e., third intention) according to the intention strength.

[0215] like Fig.14 As shown, if the target user tag is "1", the electronic device determines that the user is an active update user, the user's update intention is active, and the user tag corresponding to reminder strategy C (i.e., the third user tag) represents active, then the target reminder strategy that the electronic device matches is reminder strategy C (i.e., the first strategy). If the target user tag is "2", the electronic device determines that the user is an ordinary update user, the user's update intention is ordinary, and the user tag corresponding to reminder strategy B represents ordinary, then the target reminder strategy that the electronic device matches is reminder strategy B. If the target user tag is "3", the electronic device determines that the user is a user who refuses to update, the user's update intention is rejection, and the user tag corresponding to reminder strategy A represents rejection, then the target reminder strategy that the electronic device matches is reminder strategy A.

[0216] In some embodiments, reminder frequencies and / or reminder methods corresponding to reminder policies A, reminder policies B, and reminder policies C are different. Specifically, the stronger the update intention represented by the user label corresponding to the reminder policy, the higher the reminder frequency corresponding to the reminder policy can be. Exemplarily, if the update intention corresponding to reminder policy A is rejection, the update intention corresponding to reminder policy B is normal, and the update intention corresponding to reminder policy C is positive, then the reminder frequency corresponding to reminder policy A (i.e., the third policy) is lower than the reminder frequency corresponding to reminder policy B (i.e., the second policy), and the reminder frequency corresponding to reminder policy B is lower than the reminder frequency corresponding to reminder policy C (i.e., the first policy). It can be understood that Fig.11 and Fig.14 The user dotting sequence shown in is only an example in the embodiment of the present application and does not constitute a limitation on the user dotting sequence (ie, user behavior sequence).

[0217] Exemplarily, based on actual user behavior data, the user's dot sequence can also be {2,3,1,0,1,1,1,1,1}, indicating that the user clicks Later 2 times, clicks Update Now (i.e. download and follow) 3 times, closes / deletes notifications 1 time, clicks to enter notifications 0 times, enters the homepage 1 time, clicks the Check for Updates button 1 time, the automatic update switch and the nightly update switch are both on, and clicks the Upgrade to Try button 1 time.

[0218] Alternatively, according to actual user behavior data, the user dot sequence can also be {2,3,1,0,1,1,0,0,1}. By comparison, the difference between the user dot sequence {2,3,1,0,1,1,0,0,1} and the user dot sequence {2,3,1,0,1,1,1,1,1} is that the states of the automatic update switch and the night update switch reflected by {2,3,1,0,1,1,0,0,1} are both off, and the rest are the same and will not be repeated.

[0219] In some embodiments, user behavior data may change over time. For example, as the number of reminders increases, the reminder pop-up operation data and reminder notification operation data may change. Accordingly, the user's tap sequence may change. Then, in order to ensure the accuracy of the target user label, once the user's tap sequence changes, the electronic device can make a prediction based on the latest user's tap sequence to obtain the latest target user label.

[0220] After the target user tag is updated, the electronic device can re-match and determine the reminder strategy based on the new target user tag. At the same time, when the electronic device polls the cloud device to request a new software version, the user tag reported by the electronic device along with the software version detection request is the current latest target user tag.

[0221] In some embodiments, because the quantization of a portion of the operation data is to record the number of user operations, if there is no constraint on the user dot sequence, the value in the user dot sequence will become larger and larger over time. As long as there is a change in the quantization value in the user dot sequence, it is a new user dot sequence. This means that there are too many types of user dot sequences, making it difficult to characterize the user's update intention through all user dot sequences.

[0222] Therefore, in the embodiments of the present application, whether it is the user dot sequence quantified in the actual application for predicting the target user label, or the user dot sequence quantified in the model training process for training the user portrait model, it is limited to the dot sequence formed by the dot data within the same software version. In other words, the user operation data corresponding to each user dot sequence is the data recorded and generated within the same software version.

[0223] In the scenario of predicting the target user label, illustratively, it is assumed that the previous software version is software version A, the current software version is software version B, and the software version currently in need of updating is software version C.

[0224] Then, before the software version is updated to software version B, Fig.11 and Fig.14 The user dot sequence {1,0,1,0,1,0,1,1,0} used to predict the target user label is a sequence formed by the user operation data generated in software version A. Similarly, after updating to software version B and before updating to software version C, Fig.11 and Fig.14 The user dot sequence {1,0,1,0,1,0,1,1,0} shown in the figure for predicting the target user label is a sequence formed by the user operation data generated in software version B.

[0225] In the model training scenario, for example, if the user labels (i.e., training user labels) used to train the user portrait model are obtained through a questionnaire, then the dot sequence (e.g., Fig.14 The historical dot sequence shown in the figure is n sequences formed by the user operation data in n software versions before the questionnaire is received. Where n is a positive integer, n≥1. For example, assuming that the software version corresponding to the questionnaire reception time is software version C, then it is necessary to obtain the user operation data corresponding to n software versions before software version C, so as to form n sequences in one-to-one correspondence.

[0226] In a specific embodiment, if there are only software version A and software version B before software version C, then n=2, and the historical dot sequence may include dot sequence A formed by user operation data generated in software version A and / or dot sequence B formed by user operation data generated in software version B. Furthermore, if there are one thousand users who provide training user labels, in the case of n=2, it means that 2000 historical dot sequences can be collected.

[0227] It is understandable that n can be set according to actual needs, and the embodiment of the present application does not impose any restrictions on this. For example, if 10 versions have been updated before software version C, but n is limited to 5, then for each electronic device that provides training user labels, 5 historical dotting sequences can be obtained. Furthermore, if one thousand users provide training user labels, 5,000 historical dotting sequences can be collected.

[0228] In general, in an embodiment of the present application, the push configuration stage configures user tags that limit the push range for the new software version to be released (i.e., push user tags), and uses the trained user portrait model to predict user tags (i.e., target user tags / first user tags) based on user behavior data to reflect the user's update intention. Furthermore, in the case where a new software version can be pushed to an electronic device, a decision is made whether to push a new software version to the electronic device by matching the push user tag and the target user tag. In addition, the electronic device can also perform update reminders according to the reminder strategy corresponding to the predicted target user tag match. In this way, version push and update reminders can be adaptively performed based on the different update intentions of different users, thereby meeting the different update requirements of different users as much as possible, thereby improving the user experience.

[0229] Another embodiment of the present application provides an electronic device, including: one or more processors and a memory. The memory is coupled to the processor respectively; one or more computer program codes are stored in the memory, and the computer program code includes computer instructions; when the processor executes the computer instructions, the electronic device can implement the software update method recorded in any of the above embodiments, and specifically can implement the two stages of version push and update reminder in the software update method recorded in any of the above embodiments.

[0230] Another embodiment of the present application provides a cloud device, including: one or more processors and memory. The memory is coupled to the processor respectively; one or more computer program codes are stored in the memory, and the computer program code includes computer instructions; when the processor executes the computer instructions, the cloud device can implement the software update method recorded in any of the above embodiments, and specifically can implement the two stages of push configuration and version push in the software update method recorded in any of the above embodiments.

[0231] Another embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor in an electronic device, the electronic device implements the software update method recorded in any of the above embodiments, and specifically can implement the two stages of version push and update reminder in the software update method recorded in any of the above embodiments.

[0232] Alternatively, when the computer program is executed by the processor in the cloud device, the cloud device implements the software update method described in any of the above embodiments, and specifically can implement the two stages of push configuration and version push in the software update method recorded in any of the above embodiments.

[0233] An embodiment of the present application also provides a computer program product, which may be an electronic device. When the computer program product runs on a computer, the computer executes each function or step in the software update method recorded in any of the above embodiments, and specifically may execute each function or step in the two stages of version push and update reminder in the software update method recorded in any of the above embodiments.

[0234] Alternatively, the computer may be a cloud device, and when the computer program product runs on the computer, the computer executes each function or step in the software update method recorded in any of the above embodiments, specifically, it may execute each function or step in the two stages of push configuration and version push in the software update method recorded in any of the above embodiments.

[0235] The present application also provides a chip system, such as Fig.15 As shown, the chip system 1500 includes at least one processor 1501 and at least one interface circuit 1502. The processor 1501 and the interface circuit 1502 can be interconnected through a line. For example, the interface circuit 1502 can be used to receive signals from other devices (such as a computer memory). For another example, the interface circuit 1502 can be used to send signals to other devices (such as the processor 1501).

[0236] For example, Fig.15The chip system shown may be included in an electronic device, and then the interface circuit 1502 may read the instruction stored in the memory and send the instruction to the processor 1501. When the instruction is executed by the processor 1501, the electronic device may execute each step in the software update method described in any of the above embodiments, and specifically, the electronic device may execute each step in the two stages of version push and update reminder in the software update method described in any of the above embodiments.

[0237] For example, Fig.15 The chip system shown may be included in a cloud device, and then the interface circuit 1502 may read the instruction stored in the memory and send the instruction to the processor 1501. When the instruction is executed by the processor 1501, the cloud device may execute each step in the software update method described in any of the above embodiments, and specifically, the cloud device may execute each step in the two stages of configuration push and version push in the software update method described in any of the above embodiments.

[0238] Of course, the chip system may also include other discrete devices, which is not specifically limited in the embodiments of the present application.

[0239] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0240] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0241] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0242] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0243] If the function of the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program codes.

[0244] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A software updating method, characterized in that: Applied to a first electronic device, the method includes: Sending a software version detection request to the cloud device, wherein the software version detection request includes a first user tag, and different first user tags correspond to different user update intentions; Receiving a target software version from the cloud device, one software version corresponds to one push user tag, and the target software version is a software version that matches the push user tag and the first user tag; The software is updated based on the target software version.

2. The method according to claim 1, characterized in that The method further comprises: Acquire user operation data, where the user operation data is user behavior data corresponding to the software update; Numerically processing the user operation data to form a user behavior sequence, wherein the user behavior sequence includes a numerical value corresponding to the digitized user operation data; A user tag is predicted according to the user behavior sequence to obtain the first user tag.

3. The method according to claim 2, characterized in that The step of predicting the user tag according to the user behavior sequence to obtain the first user tag includes: Inputting the user behavior sequence into a user portrait model, and having the user portrait model predict a user label based on the user behavior sequence, and outputting the first user label; Among them, the user portrait model is obtained by taking at least one historical behavior sequence as input and a second user label associated with the at least one historical behavior sequence as a learning target for model training; the at least one historical behavior sequence is obtained by numerical processing based on historical user operation data; and the second user label is determined based on user feedback.

4. The method according to claim 2 or 3, characterized in that: The user operation data includes any one or more of the reminder pop-up box operation data corresponding to the software update, the reminder notification operation data, the upgrade homepage operation data, the check update operation data, the update switch operation data, and the advance upgrade operation data; Among them, the numerical value corresponding to the reminder pop-up operation data includes the number of operations in which the user triggers a later update and the number of operations in which the user triggers an immediate update; the numerical value corresponding to the reminder notification operation data includes the number of operations in which the user triggers closing the notification and the number of operations in which the user triggers entering the notification; the numerical value corresponding to the enter upgrade homepage operation data includes the number of operations in which the user triggers entering the homepage; the numerical value corresponding to the check update operation data includes the number of operations in which the user clicks the Check Update button; the numerical value corresponding to the advance upgrade operation data includes the number of operations in which the user clicks the advance upgrade button; the numerical value corresponding to the update switch operation data includes a first numerical value and a second numerical value, and the first numerical value and the second numerical value represent different switch states.

5. The method according to any one of claims 2 to 4, characterized in that: The user behavior sequence is updated as the user operation data changes; the user operation data corresponding to the user behavior sequence is operation data generated within the same software version.

6. The method according to any one of claims 1 to 5, characterized in that The performing software update based on the target software version includes: When the automatic update conditions are met, automatically run and install the target software version to complete the software update; When the automatic update conditions are not met, the target reminder strategy is determined according to the first user tag, and the user is prompted to manually update the software according to the target reminder strategy; wherein different first user tags correspond to different target reminder strategies, and different target reminder strategies correspond to different reminder frequencies and / or reminder methods; the reminder method includes a display method for displaying update reminder information.

7. The method according to claim 6, characterized in that The first electronic device has a candidate reminder strategy pre-stored therein; the candidate reminder strategy includes a third user tag; and the target reminder strategy is a candidate reminder strategy in which the third user tag matches the first user tag.

8. The method according to claim 7, characterized in that The user update intention is divided into a first intention, a second intention and a third intention according to the intention strength from high to low; the candidate reminder strategies include a first strategy, a second strategy and a third strategy; wherein the third user tag corresponding to the first strategy represents the first intention; the third user tag corresponding to the second strategy represents the second intention; the third user tag corresponding to the third strategy represents the third intention; the determining of the target reminder strategy according to the first user tag includes: When the first user tag represents the first intention, using the first strategy as the target reminder strategy; When the first user tag represents the second intention, using the second strategy as the target reminder strategy; When the first user tag represents the third intention, the third strategy is used as the target reminder strategy; wherein the reminder frequency corresponding to the first strategy is higher than the reminder frequency corresponding to the second strategy, and the reminder frequency corresponding to the second strategy is higher than the reminder frequency corresponding to the third strategy.

9. A software updating method, characterized in that: Applied to a cloud device, the method includes: receiving a software version detection request from a first electronic device, wherein the software version detection request includes a first user tag, and different first user tags correspond to different user update intentions; In response to the software version detection request, if it is determined that a target software version exists, the target software version is pushed to the first electronic device; wherein the software version stored in the cloud device corresponds to a push user tag, and the target software version is a software version whose push user tag matches the first user tag.

10. The method according to claim 9, characterized in that The first user tag is predicted by using a user portrait model; the method further includes: receiving at least one historical behavior sequence from a second electronic device, wherein the at least one historical behavior sequence is obtained based on historical user operation data; Acquire a second user tag from the second electronic device, where the second user tag is determined based on user feedback; Associating the at least one historical behavior sequence with the second user tag, performing model training with the at least one historical behavior sequence as input and the associated second user tag as a learning target, to obtain the user portrait model; The user portrait model is sent to the first electronic device; wherein the second electronic device includes the first electronic device or the second electronic device does not include the first electronic device.

11. The method according to claim 10, characterized in that For each historical behavior sequence, the historical user operation data corresponding to the historical behavior sequence is operation data generated in the same software version; The method further includes: performing data cleaning on the at least one historical behavior sequence to filter out abnormal historical behavior sequences and invalid historical behavior sequences.

12. An electronic device, characterized in that: include: One or more processors and a memory, wherein the memory is coupled to the processor; one or more computer program codes are stored in the memory, and the computer program codes include computer instructions; when the processor executes the computer instructions, the electronic device executes the software update method as described in any one of claims 1 to 8.

13. A cloud device, characterized in that: include: One or more processors and a memory, wherein the memory is coupled to the processor; one or more computer program codes are stored in the memory, and the computer program codes include computer instructions; when the processor executes the computer instructions, the cloud device executes the software update method as described in any one of claims 9 to 11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor of an electronic device, the electronic device executes the software update method as described in any one of claims 1-8; or, when the computer program is executed by a processor of a cloud device, the cloud device executes the software update method as described in any one of claims 9-11.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor in an electronic device, the electronic device executes the software update method as described in any one of claims 1-8; or, when the computer program is executed by a processor in a cloud device, the electronic device executes the software update method as described in any one of claims 9-11.

Images