Update control method, device, chip system, storage medium and program product

Abstract

The application discloses an updating control method and device, a chip system, a storage medium and a program product, and belongs to the technical field of computers. The method comprises the following steps: after a first device receives an updating query request sent by a second device, if it is determined that the second device has an updating demand, a device identifier of the second device is mapped to a random number in a preset value range, a target value range corresponding to a current date in the preset value range is determined according to interval days between a preset date and the current date and a target equal division value (namely n), if the random number is not in the target value range, the second device is prohibited from performing a silent updating on the current date, and if the random number is in the target value range, the second device is allowed to perform the silent updating on the current date. The application schedules all the silent updating traffics of the second devices in one day to n days, realizes uniform distribution of the traffics, and thus the downloading speed during the silent updating can be improved, and the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an update control method, device, chip system, storage medium and program product. Background Technology

[0002] Currently, mobile phones typically have an app store application (APP) installed, allowing users to download and install desired applications. Furthermore, the app store app can manage and update various applications installed on the phone.

[0003] During update management, the app store app can periodically check the server for updated versions of various applications installed on the phone. If an updated version of an application exists, and the silent update function is enabled, the app store app can automatically download the update data for that application from the server and update the application accordingly.

[0004] However, if a large number of mobile phones perform silent updates at the same time, it will result in a large amount of download traffic during that period, which can easily affect download speed and consequently affect user experience. Summary of the Invention

[0005] This application provides an update control method, device, chip system, storage medium, and program product, which can improve download speed during silent updates and enhance user experience. The technical solution is as follows:

[0006] Firstly, an update control method is provided. This method is applied to a first device, which receives an update query request sent by a second device. If it is determined that the second device has an update requirement, the device identifier of the second device is mapped to a random number within a preset numerical range. Based on the number of days between a preset date and the current date, and a target equal division value, a target numerical range corresponding to the current date within the preset numerical range is determined. The target numerical range is one of the portions obtained by dividing the preset numerical range into n equal parts, where n is the target equal division value and n is an integer greater than or equal to 2. If the random number is not within the target numerical range, the second device is prohibited from performing a silent update on the current date; if the random number is within the target numerical range, the second device is allowed to perform a silent update on the current date.

[0007] The preset value range can be set in advance. For example, the preset value range can include at least 100 different integers. For instance, the preset value range can include 100 consecutive or non-consecutive integers, such as integers from 0 to 99, integers from 1 to 100, or integers from 2 to 101, etc.

[0008] Within a preset value range, the same device identifier maps to the same random number. That is, each time the first device receives an update query request from the same second device, the first device maps the second device's device identifier to the same random number within the preset value range. Different device identifiers may map to the same or different random numbers within the preset value range. Because there are a sufficient number of second devices communicating with the first device, the distribution of random numbers mapped to the device identifiers of these second devices within the preset value range is relatively uniform, without significant skewness.

[0009] It should be noted that dividing the preset numerical range into n equal parts will result in n numerical ranges, and the target numerical range is the numerical range corresponding to the current date among these n numerical ranges.

[0010] Dividing a preset numerical range into n equal parts means dividing all integers within the preset numerical range into n parts, where the number of integers in each part is equal or nearly equal. That is, the n equal parts in this application are not necessarily strictly equal; they can be slightly different, as long as the number of integers in each part is relatively close.

[0011] The target equal division value is used to instruct all second devices to evenly distribute their original silent updates within a day over n days, which is equivalent to an n-day cycle. Therefore, based on the number of days between the preset date and the current date, and the target equal division value, the first device can determine which day of the current cycle (i.e., n days) the current date falls within. Correspondingly, it can determine which of the n parts (the n equal parts of the preset value range) the current date corresponds to, i.e., the target value range corresponding to the current date within the preset value range. In this case, the second device identified by a device identifier mapped to an integer within the target value range is allowed to perform a silent update on the current date, while the second device identified by a device identifier mapped to an integer outside the target value range is prohibited from performing a silent update on the current date.

[0012] In this application, the first device can evenly distribute all the silent updates that the second devices originally planned to perform within one day over n days. That is, it can schedule all the silent update traffic from the second devices that was originally planned within one day over n days, achieving a uniform distribution of traffic. This not only improves download speed and user experience during silent updates, but also allows for dynamic control of instantaneous bandwidth by dynamically adjusting silent update traffic. This can, to a certain extent, prevent excessive daily peak bandwidth and achieve the goal of controlling CDN costs.

[0013] In one possible implementation, the operation of mapping the device identifier of the second device to a random number within a preset numerical range can be: obtaining the hash value of the device identifier of the second device; using the hash value as a random number seed to initialize the random number generator; and generating a random number within the preset numerical range using the initialized random number generator.

[0014] The random number seed determines the initial state of the random number generator. Using the same random number seed ensures the generator produces the same sequence of random numbers, while different seeds result in different sequences, thus guaranteeing randomness. For the same device identifier, using its hash value as the seed to initialize the generator guarantees that the generated random number sequence is always the same. Therefore, for the same device identifier, the random number generator will always generate the same random number within a preset value range. In this way, the same device identifier will always map to the same random number within the preset value range.

[0015] In one possible implementation, before determining the target value range corresponding to the current date within the preset value range based on the number of days between the preset date and the current date, and the target score, the target score can be obtained by dividing 1 by a preset ratio and rounding it up. The preset ratio can be a ratio pre-configured by technicians, used to indicate the maximum percentage of all second devices allowed to perform silent updates each day.

[0016] Alternatively, the target average can be obtained by dividing 100 by the target fraction and rounding it up; then, the target average can be divided by 100 to obtain the target average percentage. The target average percentage is used to indicate, on average, what percentage of all second devices are allowed to perform silent updates each day.

[0017] In one possible implementation, the operation of determining the target value range corresponding to the current date within the preset value range based on the number of days between the preset date and the current date and the target equal score can be as follows: perform a modulo operation between the number of days between the preset date and the current date and the target equal score to obtain the target remainder; determine the target value range corresponding to the current date within the preset value range based on the target remainder.

[0018] The target remainder is an integer greater than or equal to 0 and less than or equal to n-1. The target remainder indicates that the current date is the (i+1)th day of the current cycle (i.e., n days), where i is the target remainder.

[0019] As an example, the operation of determining the target value range corresponding to the current date within the preset value range based on the target remainder can be: determining the target value range as the (i+1)th part obtained after dividing the preset value range n into equal parts.

[0020] In this case, the first device pre-divides the preset numerical range into n equal parts. After obtaining the target remainder (i.e., i), it can directly determine the (i+1)th part of the n parts obtained after dividing the preset numerical range into n equal parts as the target numerical range.

[0021] As another example, the preset value range includes integers from 0 to 99. The operation of determining the target value range corresponding to the current date within the preset value range based on the target remainder can be as follows: the range within the preset value range that is greater than or equal to i times the target average and less than i+1 times the target average is determined as the target value range.

[0022] When the preset numerical range includes integers from 0 to 99, the range of integers greater than or equal to 0 times the target average and less than 100 and the smaller of n times the target average is consistent with the preset numerical range. The range greater than or equal to i times the target average and less than i+1 times the target average is one of the portions obtained after dividing the entire range into n equal parts. Therefore, in this case, the first device does not need to pre-divide the preset numerical range into n equal parts; it can directly determine the target numerical range based on the target remainder (i.e., i) and the target average, thus allowing for a simple and quick determination of the target numerical range.

[0023] As another example, the operation of determining the target value range corresponding to the current date within the preset value range based on the target remainder can be as follows: the range that is greater than i times the target average ratio and less than or equal to i+1 times the target average ratio is determined as the target ratio range; the value range corresponding to the target ratio range within the preset value range is determined as the target value range.

[0024] The range of values ​​corresponding to the target ratio range within the preset range refers to all integers within the preset range that fall within the target ratio range.

[0025] The range of proportions greater than 0 times the target average proportion and less than or equal to the smaller of 1 and n times the target average proportion is the range (0, 100%). The range of proportions greater than i times the target average proportion and less than or equal to i+1 times the target average proportion is one of the portions obtained after dividing the entire range into n equal parts. Therefore, in this case, the first device does not need to pre-divide the preset numerical range into n equal parts; it can directly determine the target proportion range based on the target remainder (i.e., i) and the target average proportion. Based on this, the target numerical range can be directly determined from the preset numerical range, thus allowing for a simple and quick determination of the target numerical range.

[0026] In one possible implementation, after determining the target value range corresponding to the current date within a preset value range, one or more target times can be determined based on the bandwidth utilization and traffic price of each time period in the m days preceding the current date, provided that the random number is within the target value range. Here, m is a positive integer, and the target time is the time during which the second device is allowed to perform silent updates within the current date.

[0027] In this application, the target time can be determined based on the bandwidth utilization and traffic price of each time period within each day of the most recent m days, so as to improve the download speed of the second device during silent updates.

[0028] In one possible implementation, determining one or more target times based on the bandwidth utilization and traffic price for each time period within each day of the previous m days can be achieved by: dividing the bandwidth utilization for each time period within each day of the previous m days by the traffic price to obtain the unit bandwidth utilization for each time period within each day of the previous m days; determining the estimated unit bandwidth utilization for each time period within the current date based on the unit bandwidth utilization for each time period within each day of the previous m days; obtaining the average unit bandwidth utilization for each time period within the current date based on the estimated unit bandwidth utilization; and determining one or more target times based on the average unit bandwidth utilization.

[0029] This unit bandwidth utilization rate indicates the bandwidth utilization obtained per unit cost. The lower the unit bandwidth utilization rate, the more bandwidth is available per unit cost, and the faster the download speed will be; the higher the unit bandwidth utilization rate, the less bandwidth is available per unit cost, and the slower the download speed will be.

[0030] This average unit bandwidth utilization rate indicates the average level of unit bandwidth utilization within the current date. Therefore, we can use this to determine the time when the unit bandwidth utilization rate is lower than this average unit bandwidth utilization rate as the target time. When the second device performs a silent update at the target time, it can achieve a faster download speed at the same cost. In this way, a balance can be struck between user download experience and CDN costs.

[0031] As an example, the operation of determining one or more target times based on the average unit bandwidth utilization rate can be as follows: determining one or more target time periods from the various time periods after the current time within the current date where the estimated unit bandwidth utilization rate is less than the average unit bandwidth utilization rate; and determining the start time of each target time period in at least one of the one or more target time periods as the target time.

[0032] As another example, the operation of determining the one or more target times based on the average unit bandwidth utilization rate can be as follows: divide the bandwidth utilization rate of the current time by the traffic price of the current time to obtain the actual unit bandwidth utilization rate of the current time; if the actual unit bandwidth utilization rate of the current time is less than the average unit bandwidth utilization rate, then determine the current time as the target time; if the actual unit bandwidth utilization rate of the current time is greater than or equal to the average unit bandwidth utilization rate, then determine one or more target time periods from the time periods after the current time within the current date where the estimated unit bandwidth utilization rate is less than the average unit bandwidth utilization rate, and determine the start time of each target time period in at least one of the one or more target time periods as the target time.

[0033] If the actual bandwidth utilization per unit at the current time is less than the average bandwidth utilization per unit, it indicates that the actual bandwidth utilization per unit at the current time is low. In this case, the first device can directly use the current time as the target time to instruct the second device to perform a silent update at the current time. This allows the second device to start the silent update as soon as possible, improving the user experience.

[0034] In one possible implementation, the operation of preventing the second device from performing a silent update on the current date can be: sending a first update message to the second device, the first update message carrying the download address of the update data and a first indication information, the first indication information being used to indicate that a silent update is prohibited on the current date.

[0035] In one possible implementation, the operation that allows the second device to perform a silent update on the current date can be: sending a second update message to the second device, the second update message carrying the download address of the update data and a second indication information, the second indication information being used to indicate that a silent update is allowed on the current date.

[0036] Secondly, an update control device is provided, which has the function of implementing the update control method described in the first aspect. The update control device includes at least one module for implementing the update control method provided in the first aspect.

[0037] Thirdly, a computer device is provided, the computer device comprising: one or more processors, and memory;

[0038] The memory is coupled to the one or more processors and is used to store computer program code, which includes computer instructions that the one or more processors invoke to cause the computer device to perform the update control method provided in the first aspect above.

[0039] Fourthly, a chip system is provided, which is applied to a computer device. The chip system includes one or more processors, which are used to invoke computer instructions to cause the computer device to execute the update control method provided in the first aspect.

[0040] Fifthly, a computer-readable storage medium is provided, the computer-readable storage medium including instructions that, when executed on a computer device, cause the computer device to perform the update control method provided in the first aspect.

[0041] In a sixth aspect, a computer program product is provided that, when the computer program product is run on a computer device, causes the computer device to execute the update control method provided in the first aspect.

[0042] The technical effects achieved by the second, third, fourth, fifth, and sixth aspects mentioned above are similar to those achieved by the corresponding technical means in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0043] Figure 1 It is a flowchart of an application update process provided by related technologies;

[0044] Figure 2 This is a schematic diagram illustrating the process of enabling and disabling the silent update function in an application market APP, as provided in an embodiment of this application.

[0045] Figure 3 This is a flowchart of an update control method provided in an embodiment of this application;

[0046] Figure 4 This is a schematic diagram illustrating a device identifier mapped to a random number within a preset numerical range, as provided in an embodiment of this application.

[0047] Figure 5 This is a schematic diagram of a manual update process provided in an embodiment of this application;

[0048] Figure 6 This is a schematic diagram of a silent update provided in an embodiment of this application;

[0049] Figure 7 This is a flowchart of another update control method provided in an embodiment of this application;

[0050] Figure 8 This is a flowchart of another update control method provided in an embodiment of this application;

[0051] Figure 9 This is a schematic diagram of a communication system provided in an embodiment of this application;

[0052] Figure 10 This is a flowchart of another update control method provided in an embodiment of this application;

[0053] Figure 11 This is a schematic diagram of the structure of an update control device provided in an embodiment of this application;

[0054] Figure 12 This is a schematic diagram of the structure of a first device provided in an embodiment of this application;

[0055] Figure 13 This is a schematic diagram of the structure of a second device provided in an embodiment of this application. Detailed Implementation

[0056] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details.

[0057] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0058] It should be understood that "one or more" as mentioned in this application refers to one, two, or more, and "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0059] To facilitate a clear description of the technical solutions of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0060] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0061] The application scenarios involved in the embodiments of this application are described below.

[0062] Currently, mobile phones typically have an app store app installed, allowing users to download and install desired applications. Furthermore, the app store app can manage the installation, uninstallation, and updates of various applications installed on the phone.

[0063] During update management, the app store app can periodically check the server for updates to various applications installed on the phone. If an update is available for an application, and the silent update function is enabled, the app store app can automatically download the update data for that application from the server when the silent update conditions are met, such as when the phone is connected to a wireless local area network (WLAN) (e.g., Wi-Fi) and the phone is in screen-off mode, and then update the application accordingly.

[0064] Silent update refers to the feature where app stores automatically update applications on a phone when the phone meets the silent update conditions. Silent update is a crucial capability for mobile phones, ensuring a good user experience by eliminating the need for manual application updates, as updates can be performed automatically in the background.

[0065] However, if a large number of mobile phones silently update at the same time, it will result in a large amount of download traffic during that period, which can easily affect download speed and consequently impact user experience. Furthermore, for mobile phone manufacturers, their servers need to transmit application update data to the app stores on the phones via a content delivery network (CDN), and manufacturers need to pay CDN providers. CDN providers typically charge based on daily peak bandwidth. A large amount of download traffic at a certain time will lead to a large instantaneous bandwidth demand, thereby increasing CDN costs. Therefore, the occurrence of download peaks not only results in a poor user experience but also increases CDN costs for mobile phone manufacturers.

[0066] The following section explains the process of updating applications using the app store on a mobile phone in the relevant technology.

[0067] Figure 1 This is a flowchart illustrating an application update process provided by related technologies. See also... Figure 1 The process includes the following steps 101 to 108:

[0068] Step 101: The app store APP sends an application update query request to the server. The application update query request carries the application identifier and version number of each of the one or more applications installed on the phone.

[0069] Step 102: After receiving the application update query request, the server determines whether there is an application to be updated in one or more applications based on the application update query request.

[0070] For example, for any one of the one or more applications, if the version number of that application is lower than the version number of the application with the same application identifier stored on the server, then that application is determined to be an application to be updated.

[0071] Step 103: The server obtains the download address of the update data for the application to be updated and obtains the configuration information.

[0072] This configuration information indicates the conditions under which the phone can perform silent updates. For example, this configuration information may include the required range of phone temperature and the required range of phone battery level.

[0073] Step 104: The server sends an application update message to the app store app, which carries the download address and configuration information.

[0074] Step 105: After receiving the application update message, if the application market APP detects that the phone status meets the conditions indicated by the configuration information when the phone screen is off, and the silent update function is enabled, it sends an application download request to the server. The application download request carries the download address.

[0075] Step 106: After receiving the application download request, the server obtains the application update data based on the download address.

[0076] Step 107: The server sends the application's update data to the app store via CDN.

[0077] Step 108: After receiving the update data for the application, the app store app updates the application based on the update data.

[0078] As can be seen from the above process, after receiving an app update notification, app stores can silently update their apps by simply matching the phone's status and cloud configuration information while the phone screen is off. This can easily cause a surge in app downloads, resulting not only in a poor user experience but also increased CDN costs for phone manufacturers.

[0079] To address this, this application provides an update control method that evenly distributes the silent updates that would otherwise occur on all mobile phones within a single day over n days. In other words, it schedules the silent update traffic from all mobile phones from a single day over n days, achieving a more uniform distribution of traffic. This not only improves download speeds during silent updates and enhances user experience, but also allows for dynamic control of instantaneous bandwidth by dynamically adjusting silent update traffic. This helps to avoid excessive daily peak bandwidth and thus controls CDN costs to a certain extent.

[0080] The following explains how to enable and disable the silent update function in app stores.

[0081] Generally, the silent update function in app stores can be enabled or disabled by the user. If the user enables the silent update function in the app store, the app store can automatically update applications; if the user disables the silent update function in the app store, the user can manually update applications.

[0082] For example, such as Figure 2 As shown in Figure (a), the mobile phone's desktop 210 displays an app store icon 211. The user can click the app store icon 211, and in response to this click, as shown... Figure 2 As shown in Figure (b), the electronic device launches the app store APP and displays the app store APP's application interface 220. The application interface 220 displays controls for "App Update," "Installation Management," "Uninstallation Management," and "Settings" 221. The user can click the "Settings" control 221, and in response to this click, as shown... Figure 2 As shown in Figure (c), the electronic device can display a settings interface 230, which includes a "Automatic Application Update" control 231, a "Data Download Reminder" control, a "Message Notification Management" control, and a "Content Management" control. The user can click the "Automatic Application Update" control 231, and in response to this click, as shown... Figure 2As shown in Figure (d), the electronic device displays an automatic update application interface 240, which includes "On," "WLAN Only," and "Off" options. Users can select any one of these options. Specifically, if the user selects "On," the app store app enables silent updates, and silent updates can be performed when the phone is connected to either WLAN or mobile network. If the user selects "WLAN Only," the app store app enables silent updates, but only when the phone is connected to WLAN; silent updates are not performed when the phone is connected to mobile network. If the user selects "Off," the app store app disables silent updates.

[0083] It should be noted that the embodiments in this application are only for reference. Figure 2 This example illustrates the process of enabling and disabling the silent update function in an app store. Figure 2 The process shown does not limit the embodiments of this application. In practical applications, the silent update function in the app store can also be enabled or disabled in other ways.

[0084] Figure 3 This is a flowchart illustrating an update control method provided in an embodiment of this application. The method is applied to an app store (APP) and a server in a mobile phone. The server can be the server corresponding to the app store, or optionally, the server of the mobile phone manufacturer. See also... Figure 3 The method includes the following steps:

[0085] Step 301: The app store app on the phone sends an app update query request to the server.

[0086] For example, the application update query request may carry the device identifier of the mobile phone, the application identifier and version number of each of the one or more applications installed on the mobile phone. Of course, the application update query request may also carry other information, such as the language currently used by the mobile phone, etc., which is not limited in this embodiment.

[0087] The device identifier of a mobile phone is used to uniquely identify the mobile phone. For example, the device identifier of a mobile phone can be a unique device identifier (UDID), a serial number (SN), or a user account logged in to the app store. This application embodiment does not limit this.

[0088] The application identifier is used to identify the application. For example, the application identifier can be the name of the application, etc., but this application embodiment does not limit this.

[0089] An application's version number indicates the version of the application. Generally, a larger version number indicates a newer version, and a smaller version number indicates an older version.

[0090] This application update query request is used to request whether an updated version of one or more applications exists.

[0091] In some embodiments, the app store app can periodically send app update query requests to the server to periodically check for the existence of updated versions of one or more applications. The period for the app store app to send these query requests can be preset. For example, the app store app can send these requests every 30 minutes, 1 hour, or 2 hours.

[0092] Each time the server receives an application update query request from the app store app, it can execute steps 302 to 308 as follows.

[0093] Step 302: After receiving the application update query request, the server determines whether any one of the one or more applications is the target application to be updated based on its application identifier and version number.

[0094] It should be noted that after developing a new version of their application, developers often release it on various application distribution platforms. Servers can retrieve and store the latest versions of various applications from these platforms.

[0095] In this case, for any one of the one or more applications, if the version number of that application is less than the version number of the application with the same application identifier stored on the server, then that application can be determined as the target application to be updated; if the version number of that application is greater than or equal to the version number of the application with the same application identifier stored on the server, then that application can be determined as not the target application to be updated.

[0096] Step 303: If there is a target application to be updated among the one or more applications, the server obtains the download address of the update data of the target application.

[0097] The number of target applications can be one or more.

[0098] The download address of an update data for a target application is used to indicate where the update data is stored on the server.

[0099] Furthermore, the server can also obtain version information of the updated version of the target application, such as size, version number, and update log, but this embodiment does not limit this.

[0100] Optionally, if there is a target application to be updated among the one or more applications, the server can also obtain configuration information. This configuration information is used to indicate the conditions that the phone state must meet during silent updates. For example, the configuration information may include the range of values ​​that the phone temperature must meet, the range of values ​​that the phone battery level must meet, etc., which are not limited in this embodiment.

[0101] This configuration information can be preset, for example, it can be preset by technicians according to requirements. For instance, all mobile phones can have the same configuration information, or mobile phones of the same model can have the same configuration information, or mobile phones of the same type can have the same configuration information, or mobile phones of the same brand can have the same configuration information; this application embodiment does not limit this.

[0102] Step 304: The server maps the device identifier of the mobile phone to a random number within a preset value range.

[0103] The preset value range can be set in advance. For example, the preset value range may include at least 100 different integers. For instance, the preset value range may include 100 consecutive or non-consecutive integers, such as integers from 0 to 99, integers from 1 to 100, or integers from 2 to 101, etc. This application embodiment does not limit this.

[0104] It should be noted that the same device identifier maps to the same random number within a preset value range. That is, each time the server receives an app update query request from an app store app on the same phone, the server will map that phone's device identifier to the same random number within the preset value range. Different device identifiers may map to the same or different random numbers within the preset value range. Because there are a sufficient number of phones communicating with the server, the distribution of random numbers mapped to these phone device identifiers within the preset value range is relatively even, without significant skewness.

[0105] For example, suppose the device identifier for phone 1 is udid1, the device identifier for phone 2 is udid2, the device identifier for phone 3 is udid3, and the device identifier for phone 4 is udid4. The default value range includes integers from 0 to 99. Then, as... Figure 4As shown, the server can map udid1 to 0 in the preset value range, udid2 to 97 in the preset value range, udid3 to 2 in the preset value range, and udid4 to 99 in the preset value range.

[0106] In some embodiments, step 304 may be as follows: the server obtains the hash value of the device identifier of the mobile phone, uses the hash value as a random number seed to initialize the random number generator, and generates a random number within a preset value range through the initialized random number generator.

[0107] For example, the server can generate a hash value for the device identifier of the mobile phone using a hash algorithm. This hash algorithm can be pre-configured. For instance, it could be the MurmurHash algorithm, Message Digest Algorithm 5 (MD5), etc., and this embodiment of the application does not limit this specific implementation.

[0108] For example, the random number generator is used to generate random numbers within a preset numerical range. For instance, the random number generator can be a pseudo-random number generator, a true random number generator, a hybrid random number generator, etc., and this application embodiment does not limit this.

[0109] The random number seed determines the initial state of the random number generator. Using the same random number seed ensures the generator produces the same sequence of random numbers, while different seeds result in different sequences, thus guaranteeing randomness. For the same device identifier, using its hash value as the seed to initialize the generator guarantees that the generated random number sequence is always the same. Therefore, for the same device identifier, the random number generator will always generate the same random number within a preset value range. In this way, the same device identifier will always map to the same random number within the preset value range.

[0110] Step 305: The server determines the target value range corresponding to the current date within the preset value range based on the number of days between the preset date and the current date, as well as the target equal score.

[0111] The preset date can be set in advance. The preset date is a date prior to the current date. For example, the preset date could be January 1, 1970.

[0112] The target numerical range is one of the portions obtained by dividing a preset numerical range into n equal parts, where n is the target division value. Specifically, dividing the preset numerical range into n equal parts yields n numerical ranges, and the target numerical range is the numerical range corresponding to the current date within those n ranges.

[0113] It should be noted that dividing the preset numerical range into n equal parts means dividing all integers within the preset numerical range into n parts, with each part containing an equal or nearly equal number of integers. For example, if the preset numerical range includes 100 different integers, dividing it into 3 equal parts will result in the first part containing 34 integers, the second part containing 34 integers, and the third part containing 32 integers, thus ensuring that the number of integers in each part is relatively close. In other words, the n equal parts in this embodiment are not necessarily strictly equal; they can be slightly different, as long as the number of integers in each part is relatively close.

[0114] The target score is an integer greater than or equal to 2. The target score is used to indicate how to evenly distribute the silent updates of all mobile phones, originally scheduled for one day, over n days. For example, assuming the target score is 3, and 10 mobile phones originally performed silent updates on the same day, this embodiment can distribute the silent updates of these 10 mobile phones more evenly over 3 days. For instance, 3 mobile phones can perform silent updates on the first day, another 3 mobile phones on the second day, and the remaining 4 mobile phones on the third day.

[0115] Optionally, the target score can be calculated based on a preset ratio.

[0116] The preset ratio can be pre-configured by technicians. This preset ratio indicates the maximum percentage of phones allowed to perform silent updates each day. It should be noted that technicians can also reset the preset ratio as needed during server operation.

[0117] For example, the server can divide 1 by a preset percentage and round the result up to obtain the target score. For instance, assuming the preset percentage is 40%, dividing 1 by 40% and rounding the result up will give the target score of 3.

[0118] Optionally, the server can also round up the value obtained by dividing 100 by the target fraction to get the target average. Dividing the target average by 100 gives the target average percentage. The target average percentage is used to indicate what percentage of all mobile phones are allowed to perform silent updates each day on average.

[0119] For example, assuming the target score is 3, we can divide 100 by 3 and round up to get the target average of 34, which means that on average, 34% of all mobile phones are allowed to perform silent updates every day.

[0120] It should be noted that since CDN providers calculate fees based on daily peak bandwidth, the preset ratio configured by the technicians in this embodiment can be averaged to obtain the target average ratio, so as to achieve the average distribution of silent updates to all mobile phones in the future.

[0121] Since the target equal division value is used to instruct all mobile phones to evenly distribute the silent updates originally scheduled for one day across n days (equivalent to an n-day cycle), the server can determine which day of the current cycle (i.e., n days) the current date falls within based on the interval between the preset date and the current date, as well as the target equal division value. Correspondingly, it can determine which of the n parts the current date corresponds to after dividing the preset value range into n equal parts, thus determining the target value range corresponding to the current date within the preset value range. In this case, mobile phones identified by device identifiers mapped to integers within the target value range are allowed to perform silent updates on the current date, while mobile phones identified by device identifiers mapped to integers outside the target value range are prohibited from performing silent updates on the current date.

[0122] In some embodiments, the operation of the server determining the target value range corresponding to the current date within the preset value range based on the number of days between the preset date and the current date and the target equal score can be as follows: the server performs a modulo operation on the number of days between the preset date and the current date and the target equal score to obtain the target remainder; and determines the target value range corresponding to the current date within the preset value range based on the target remainder.

[0123] The target remainder is an integer greater than or equal to 0 and less than or equal to n-1. The target remainder indicates that the current date is the (i+1)th day of the current cycle (i.e., n days), where i is the target remainder.

[0124] Optionally, the server's operation of determining the target value range corresponding to the current date within a preset value range based on the target remainder can include the following three methods:

[0125] The first method: The server determines the target value range as the (i+1)th part obtained by dividing the preset value range n into equal parts.

[0126] In this case, the server pre-divides the preset numerical range into n equal parts. After obtaining the target remainder (i.e., i), it can directly determine the (i+1)th part of the n parts obtained after dividing the preset numerical range into n equal parts as the target numerical range.

[0127] For example, suppose the preset value range includes 100 different integers. After dividing the preset value range into three equal parts, the first part contains 34 integers, the second part contains 34 integers, and the third part contains 32 integers. If the target remainder is 0, the server can determine that the target value range is the 34 integers in the first part; if the target remainder is 1, the server can determine that the target value range is the 34 integers in the second part; and if the target remainder is 2, the server can determine that the target value range is the 32 integers in the third part.

[0128] The second method: The preset numerical range includes integers from 0 to 99. The server determines the target numerical range as the range of values ​​within the preset numerical range that are greater than or equal to i times the target average and less than i+1 times the target average.

[0129] When the preset numerical range includes integers from 0 to 99, the range of integers greater than or equal to 0 times the target average and less than 100 and the smaller of n times the target average is consistent with the preset numerical range. The range greater than or equal to i times the target average and less than i+1 times the target average is one of the parts obtained by dividing the entire range into n equal parts. Therefore, in this case, the server does not need to pre-divide the preset numerical range into n equal parts; it can directly determine the target numerical range based on the target remainder (i.e., i) and the target average, thus allowing for a simple and quick determination of the target numerical range.

[0130] For example, the preset numerical range includes integers from 0 to 99, and the target average is 34. If the target remainder is 0, the server can define the target numerical range as the range of integers greater than or equal to 0 and less than 34 within the preset numerical range, meaning the target numerical range includes integers from 0 to 33. If the target remainder is 1, the server can define the target numerical range as the range of integers greater than or equal to 34 and less than 68 within the preset numerical range, meaning the target numerical range includes integers from 34 to 67. If the target remainder is 1, the server can define the target numerical range as the range of integers greater than or equal to 68 and less than 102 within the preset numerical range, meaning the target numerical range includes integers from 68 to 99.

[0131] The third method: The server determines the range that is greater than i times the target average ratio and less than or equal to i+1 times the target average ratio as the target ratio range, and determines the range of values ​​corresponding to the target ratio range in the preset value range as the target value range.

[0132] The range of values ​​corresponding to the target ratio range within the preset range refers to all integers within the preset range that fall within the target ratio range.

[0133] The range of proportions greater than 0 times the target average and less than or equal to the smaller of 1 and n times the target average is the range (0, 100%). The range of proportions greater than i times the target average and less than or equal to i+1 times the target average is one of the portions obtained by dividing the entire range into n equal parts. Therefore, in this case, the server does not need to pre-divide the preset numerical range into n equal parts; it can directly determine the target proportion range based on the target remainder (i.e., i) and the target average proportion. Based on this, the target numerical range can be directly determined from the preset numerical range, thus allowing for a simple and quick determination of the target numerical range.

[0134] For example, suppose the preset numerical range includes 100 different integers, and the target average percentage is 34%. If the target remainder is 0, the server can determine the target numerical range as the integers within the preset numerical range located in (0, 34%), meaning the target numerical range includes the first 34 integers in the preset numerical range. If the target remainder is 1, the server can determine the target numerical range as the integers within the preset numerical range located in (34%, 68%), meaning the target numerical range includes the 35th to 68th integers in the preset numerical range. If the target remainder is 2, the server can determine the target numerical range as the integers within the preset numerical range located in (68%, 102%), meaning the target numerical range includes the 69th to 100th integers in the preset numerical range.

[0135] It should be noted that there is no strict order in which steps 304 and 305 are executed. That is, step 304 can be executed first and then step 305, or step 305 can be executed first and then step 304, or steps 304 and 305 can be executed in parallel.

[0136] If the random number mapped to the device identifier of the mobile phone within the preset value range is not within the target value range, the server prohibits the mobile phone from performing a silent update on the current date, and then executes step 306; if the random number is within the target value range, the server allows the mobile phone to perform a silent update on the current date, and then executes steps 307 to 308.

[0137] Step 306: If the random number is not within the target value range, the server sends an application update message to the application market APP.

[0138] For example, the application update message may carry the download address of the update data for each of the one or more target applications to be updated, and a first instruction message indicating that silent updates are prohibited on the current date.

[0139] Optionally, the application update message may also carry version information of the updated version of each of the one or more target applications, and / or configuration information, etc., which are not limited in this embodiment.

[0140] After receiving the application update message, the app store app can learn from the first indication information carried in the application update message that silent updates are prohibited on the current date. Therefore, even if the app store app has enabled the silent update function, it will not perform a silent update on the current date, that is, it will not download the update data of the target application from the server on the current date.

[0141] In some embodiments, although the app store app cannot be silently updated on the current date, users can still manually update the target application.

[0142] Specifically, after receiving the application update message, the app store app can display an update button for the target application on the application update interface. In this case, if the app store app receives a trigger action on the update button, it can send an application download request to the server carrying the download address of the target application's update data. After receiving the application download request, the server can obtain the update data based on the download address carried in the application download request and send the update data to the app store app. After receiving the update data, the app store app can update the target application according to the update data.

[0143] For example, the server can send the update data to the app store app via a CDN. This improves the reliability and stability of data transmission and increases the download speed of the update data.

[0144] The trigger for the update button on the target application can be a user-initiated action, such as clicking the update button. If the app store app receives this trigger, it means the user has instructed that the target application be updated. Therefore, the app store app can download the update data for the target application from the server and update the target application accordingly.

[0145] For example, such as Figure 5 As shown in Figure (a), the mobile phone displays the application interface 220 of the app market. The application interface 220 displays an "App Update" control 222, an "Installation Management" control, an "Uninstallation Management" control, and a "Settings" control. The user can click the "App Update" control 222, and in response to this click, as shown... Figure 5As shown in Figure (b), the electronic device can display an application update interface 250, which displays an update button 251 and a one-click update button 252 for each of the one or more target applications to be updated. If a user wants to update one of the target applications, the user can click the update button 251 of that target application. In response to this click, the application market APP can update the target application, specifically by downloading the update data of the target application from the server. If a user wants to update all target applications in batches, the user can click the one-click update button 252. In response to this click, the application market APP can update all of the one or more target applications, specifically by downloading the update data of each of the one or more target applications from the server.

[0146] It should be noted that the embodiments in this application are only for reference. Figure 5 The process shown is used as an example to illustrate the manual update process. Figure 5 The process shown does not limit the embodiments of this application. In practical applications, manual updates can also be performed in other ways.

[0147] Step 307: If the random number is within the target value range, the server determines one or more target times based on the bandwidth utilization and traffic price of each time period in the m days prior to the current date, where m is a positive integer.

[0148] The target time is the time during which the phone is allowed to perform silent updates within the current date.

[0149] m can be preset. For example, m can be 2, 3, 4, 7, etc., but this application embodiment does not limit this.

[0150] The time periods mentioned herein can be in the minute range, such as 1 minute, 5 minutes, 30 minutes, etc., or in the hour range, such as 1 hour, 2 hours, etc. The embodiments of this application do not limit this.

[0151] Bandwidth utilization rate represents the ratio of the amount of bandwidth used per unit of time to the total available bandwidth.

[0152] Traffic pricing represents the cost required to transmit a certain amount of data.

[0153] For example, the server can obtain the bandwidth utilization rate of each time period within each day of the m days prior to the current date (i.e., the most recent m days) from the CDN provider; or, the server can analyze the application download status of all mobile phones in the m days prior to the current date to obtain the bandwidth utilization rate of each time period within each day of those m days; of course, the server can also obtain the bandwidth utilization rate of each time period within each day of the m days prior to the current date through other methods, and this application embodiment does not limit this.

[0154] For example, the server can obtain the traffic price for each time period of each day within the previous m days from the CDN provider. Of course, the server can also obtain the traffic price for each time period of each day within the previous m days through other means, and this application embodiment does not limit this.

[0155] In some embodiments, step 307 may be performed as follows: the server divides the bandwidth utilization rate of each time period in each day of the previous m days by the traffic price to obtain the unit bandwidth utilization rate of each time period in each day of the previous m days; estimates the unit bandwidth utilization rate of each time period in the current date based on the unit bandwidth utilization rate of each time period in each day of the previous m days (hereinafter referred to as the estimated unit bandwidth utilization rate); obtains the average value of the estimated unit bandwidth utilization rate of each time period in the current date (hereinafter referred to as the average unit bandwidth utilization rate); and determines one or more target times based on the average unit bandwidth utilization rate.

[0156] This unit bandwidth utilization rate indicates the bandwidth utilization obtained per unit cost. The lower the unit bandwidth utilization rate, the more bandwidth is available per unit cost, and the faster the download speed will be; the higher the unit bandwidth utilization rate, the less bandwidth is available per unit cost, and the slower the download speed will be.

[0157] This average unit bandwidth utilization rate indicates the average level of unit bandwidth utilization within the current date. Therefore, we can use this to determine the time when the unit bandwidth utilization rate is lower than this average unit bandwidth utilization rate as the target time. When the mobile phone performs a silent update at the target time, it can achieve a faster download speed at the same cost. In this way, a balance can be struck between user download experience and CDN costs.

[0158] Optionally, the server can estimate the unit bandwidth utilization rate for each time period within the current date based on the unit bandwidth utilization rate for each time period within each day of the previous m days. This can be done by: for any time period within a day, taking a weighted average of the unit bandwidth utilization rate for that time period within each day of the previous m days to obtain the estimated unit bandwidth utilization rate for that time period within the current date.

[0159] The weights for each day of the m days can be preset. Each day's weight is greater than 0 and less than 1, and the sum of the weights for each day of the m days is 1. For example, the weights for each day of the m days can be the same; or, the weights of dates closer to the current date can be greater, and the weights of dates farther from the current date can be smaller.

[0160] For example, assuming m is 3, then for the 3 days before the current date, we can set the weight of the date 1 day before the current date to 0.5, the weight of the date 2 days before the current date to 0.3, and the weight of the date 3 days before the current date to 0.2. Assuming the current date is June 1, 2024, then the m days before the current date are May 31, 2024, May 30, 2024, and May 29, 2024. We can then set the weight of May 31, 2024 to 0.5, the weight of May 30, 2024 to 0.3, and the weight of May 29, 2024 to 0.2.

[0161] Alternatively, the server can determine one or more target times based on this average unit bandwidth utilization in two ways:

[0162] The first method: The server determines one or more target time periods from the time periods after the current time within the current date, where the estimated unit bandwidth utilization is less than the average unit bandwidth utilization, and determines the start time of each target time period in at least one of the one or more target time periods as the target time.

[0163] If the total number of the one or more target time periods is less than or equal to a preset number, the server can determine the start time of each target time period as the target time. If the total number of the one or more target time periods is greater than the preset number, the server can sort the one or more target time periods in ascending order of estimated unit bandwidth utilization or in ascending order of time distance from the current time, and determine the start time of each of the first j target time periods in the sorted one or more target time periods as the target time, where j is the preset number. The preset number can be set in advance, for example, it can be 2, 3, 4, etc., and this embodiment does not limit this.

[0164] It should be noted that if there is no target time period with an estimated unit bandwidth utilization rate lower than the average unit bandwidth utilization rate in any time period after the current time within the current date, it means that the estimated unit bandwidth utilization rate in any time period after the current time within the current date is relatively high.

[0165] In this case, as an optional approach, the server can determine that no time period after the current time within the current date is suitable for silent updates. In this case, the server can prevent the phone from performing silent updates on the current date, and the operation of sending an application update message to the app store in step 306 above can be performed.

[0166] As an alternative approach, the server can determine the target time as the start time of the time period with the lowest estimated unit bandwidth utilization among all time periods after the current time within the current date.

[0167] The second method: The server obtains the bandwidth utilization and traffic price at the current time, divides the bandwidth utilization at the current time by the traffic price at the current time to obtain the unit bandwidth utilization at the current time (hereinafter referred to as the actual unit bandwidth utilization); if the actual unit bandwidth utilization at the current time is less than the average unit bandwidth utilization, then the current time is determined as the target time; if the actual unit bandwidth utilization at the current time is greater than or equal to the average unit bandwidth utilization, then one or more target times are determined by the first method mentioned above.

[0168] For example, the server can obtain the bandwidth utilization rate for the current time from the CDN provider; or, the server can analyze the application download status of all mobile phones at the current time to obtain the bandwidth utilization rate for the current time; of course, the server can also obtain the bandwidth utilization rate for the current time through other means, which are not limited in this embodiment.

[0169] For example, the server can obtain the current traffic price from the CDN provider. Of course, the server can also obtain the current traffic price through other means, which is not limited in this embodiment of the application.

[0170] If the actual bandwidth utilization per unit at the current time is less than the average bandwidth utilization per unit, it indicates that the actual bandwidth utilization per unit at the current time is low. In this case, the server can directly use the current time as the target time to instruct the phone to perform a silent update at that time. This allows the phone to start the silent update as quickly as possible, improving the user experience.

[0171] It should be noted that if the server determines multiple target times in step 307, the server can also determine the priority of each target time among these multiple target times.

[0172] For example, the server can determine the priority of each of the multiple target times based on the time interval between each target time and the current time.

[0173] Specifically, the server can prioritize each of the multiple target times according to their distance from the current time, from shortest to longest, so that it can subsequently instruct the phone to perform a silent update at the nearest target time. This allows the phone to begin the silent update as quickly as possible, improving the user experience.

[0174] Step 308: The server sends an application update message to the app in the app store.

[0175] For example, the application update message may carry the download address of the update data for each of the one or more target applications to be updated, and a second instruction to indicate that a silent update is allowed on the current date.

[0176] Furthermore, the application update message may also carry one or more target times, and optionally, the priority of each target time among multiple target times.

[0177] Optionally, the application update message may also carry version information of the updated version of each of the one or more target applications, and / or configuration information, etc., which are not limited in this embodiment.

[0178] After receiving the app update message, the app store app can determine from the second indication information carried in the update message that a silent update is allowed on the current date. In this case, if the update message does not carry a target time, the app store app can determine that a silent update is allowed throughout the current date; if the update message carries a target time, the app store app can determine that a silent update is allowed during one or more target times within the current date.

[0179] In some embodiments, if the application update message does not carry a target time, the app store app, with silent update enabled, can send an application download request to the server if it detects that the phone status meets preset conditions and the conditions indicated by the configuration information within the current date. This application download request carries the download address of the update data for each of the one or more target applications to be updated. Upon receiving the application download request, the server can obtain the update data for each target application based on its download address and send this update data to the app store app. After receiving the update data, the app store app updates each target application according to its update data.

[0180] The preset conditions can be set in advance. For example, the preset condition can be that the mobile phone is in a screen-off state; or, the preset condition can be that the mobile phone is in a screen-off state and the mobile phone is connected to WLAN; of course, the preset condition can also be other conditions, which are not limited in this embodiment.

[0181] For example, when the user selects Figure 2 When the "Open" option is selected in the automatic update application interface 240 shown in Figure (d), the app store APP can set the preset condition that the phone is in a screen-off state; and when the user selects Figure 2 In the case of the "WLAN only" option in the automatic update application interface 240 shown in Figure (d), the application market APP can set the preset conditions as the phone being in a screen-off state and the phone being connected to WLAN.

[0182] In other embodiments, if the application update message carries one or more target times, then when the application market app has silent update enabled, if it detects that the time difference between the current time and any one of the target times within the current date is less than or equal to a preset time, and detects that the phone status meets preset conditions and the conditions indicated by the configuration information, it can send an application download request to the server. This application download request carries the download address of the update data for each of the one or more target applications to be updated. After receiving the application download request, the server can obtain the update data for each target application based on the download address of the update data for each of the one or more target applications, and send the update data for each of the one or more target applications to the application market app. After receiving the update data for each of the one or more target applications, the application market app updates each target application according to the update data for each target application.

[0183] The preset duration can be set in advance. For example, the preset duration can be 3 minutes, 5 minutes, etc., but this application embodiment does not limit this.

[0184] It should be noted that in this embodiment of the application, the mobile phone may be instructed to have the right to silently update at one or more target times within the current date, while it may not be able to silently update at other times, thereby avoiding to some extent the situation of never updating the application and repeatedly updating the application.

[0185] For example, the server can use a CDN to send update data of the target application to the app store. This improves the reliability and stability of data transmission and increases the download speed of the update data.

[0186] In some embodiments, if the silent update function in the app store is not enabled, the app store cannot perform silent updates, but users can still manually update the target application. The specific steps for this manual update can be found in the description of step 306, and will not be repeated here.

[0187] In this embodiment, after receiving an application update query request from an app store app on a mobile phone, if the server determines that the target application to be updated exists on the phone, it maps the phone's device identifier to a random number within a preset value range. Based on the number of days between the preset date and the current date, and the target equal score (i.e., n), the server determines the target value range corresponding to the current date within the preset value range. If the random number is not within the target value range, the server prohibits the phone from performing a silent update on the current date; if the random number is within the target value range, the server allows the phone to perform a silent update on the current date. In this way, the silent updates that were originally scheduled for one day can be evenly distributed across n days, that is, the silent update traffic that was originally scheduled for one day can be scheduled across n days, achieving a uniform distribution of traffic. This not only improves the download speed during silent updates and enhances the user experience, but also allows for dynamic control of instantaneous bandwidth by dynamically adjusting silent update traffic, thereby avoiding excessive daily peak bandwidth and controlling CDN costs to a certain extent.

[0188] For example, in related technologies, such as Figure 6 As shown in Figure (a), all mobile phones ( Figure 6 Taking mobile phones 1 to 10 as examples, they can perform silent updates every day, which can easily lead to excessive daily download traffic and consequently excessive daily peak bandwidth. This not only results in a poor user experience but also brings high CDN costs to mobile phone manufacturers.

[0189] Therefore, the embodiments of this application provide the above-mentioned Figure 3 The update control method described in the embodiment assumes that n is 3, such as... Figure 6As shown in Figure (b), all mobile phones can be divided into three groups. Phones 1, 2, and 3 in the first group can perform silent updates on the first day of each cycle (n days), such as on days 1, 4, 7, etc. Phones 4, 5, and 6 in the second group can perform silent updates on the second day of each cycle, such as on days 2, 5, 8, etc. Phones 7, 8, 9, and 10 in the third group can perform silent updates on the third day of each cycle, such as on days 3, 6, 9, etc. In this way, the silent updates that would normally occur within a single day are evenly distributed over three days, thus achieving a more uniform distribution of traffic. This not only improves the user download experience but also reduces CDN costs.

[0190] It should be noted that the embodiments of this application can be applied not only to scenarios where an app store APP on a mobile phone updates various applications on the mobile phone, but also to scenarios where an application updates itself, or to scenarios where a settings application on a mobile phone updates the operating system of the mobile phone. Of course, it can also be applied to other update scenarios, and the embodiments of this application do not limit them.

[0191] The following explains the process of enabling and disabling the silent update function in a certain application.

[0192] Generally, the silent update feature in an application can be enabled or disabled by the user. If the user enables the silent update feature, the application can update automatically; if the user disables the silent update feature, the user can update the application manually.

[0193] For example, with Figure 2 The process is similar. Users can open the application on their phone and find the option or switch to turn the silent update function on or off in the application's interface. Users can turn the silent update function in the application on or off by operating the corresponding option or switch.

[0194] Figure 7 This is a flowchart illustrating an update control method provided in an embodiment of this application. The method is applied to an application and a server in a mobile phone. The server can be the server corresponding to the application, or optionally, the server of the application's developer. See also... Figure 7 The method includes the following steps:

[0195] Step 701: The application on the phone sends an application update query request to the server.

[0196] For example, the application update query request may carry the device identifier of the mobile phone and the version number of the application. Of course, the application update query request may also carry other information, such as the language currently used by the mobile phone, etc., which is not limited in this embodiment.

[0197] The device identifier and application version number of the mobile phone have already been explained in step 301 above, and will not be repeated here.

[0198] This application update query request is used to query whether an updated version of the application exists.

[0199] In some embodiments, the application can periodically send application update query requests to the server to periodically check if an updated version of the application exists. The frequency of these requests can be preset. For example, the application can send application update query requests to the server every 30 minutes, 1 hour, or 2 hours.

[0200] Each time the server receives an application update query request from the application, it can execute steps 702 to 708 as follows.

[0201] Step 702: After receiving the application update query request, the server determines whether the application needs to be updated based on the application's version number.

[0202] It should be noted that after developing a new version of the application, the developer will store it on a server. In this case, if the application's version number is less than the version number of the application stored on the server, it can be determined that the application needs to be updated; if the application's version number is greater than or equal to the version number of the application stored on the server, it can be determined that the application does not need to be updated.

[0203] Step 703: If the application needs to be updated, the server obtains the download address of the application's update data.

[0204] The download address for the application's update data indicates where the update data is stored on the server.

[0205] Furthermore, the server can also obtain version information of the updated version of the application, such as size, version number, change log, etc., which is not limited in this embodiment of the application.

[0206] Optionally, the server can also obtain configuration information if the application needs to be updated. This configuration information has already been described in step 303 above and will not be repeated here.

[0207] Step 704: The server maps the device identifier of the mobile phone to a random number within a preset value range.

[0208] The operation of step 704 is similar to that of step 304 above, and will not be described again in this embodiment.

[0209] Step 705: The server determines the target value range corresponding to the current date within the preset value range based on the number of days between the preset date and the current date, as well as the target equal score.

[0210] The operation of step 705 is similar to that of step 305 above, and will not be described again in this embodiment.

[0211] It should be noted that there is no strict order in which steps 704 and 705 are executed. That is, step 704 can be executed first and then step 705, or step 705 can be executed first and then step 704, or steps 704 and 705 can be executed in parallel.

[0212] If the random number mapped to the device identifier of the mobile phone within the preset value range is not within the target value range, the server prohibits the mobile phone from performing a silent update on the current date, and then executes step 706; if the random number is within the target value range, the server allows the mobile phone to perform a silent update on the current date, and then executes steps 707 to 708.

[0213] Step 706: If the random number is not within the target value range, the server sends an application update message to the application.

[0214] For example, the application update message may carry the download address of the application's update data and a first instruction message indicating that silent updates are prohibited on the current date.

[0215] Optionally, the application update message may also carry version information of the updated version of the application, and / or configuration information, etc., which are not limited in this embodiment.

[0216] After receiving the application update message, the application can learn from the first indication information carried in the application update message that silent updates are prohibited on the current date. Therefore, even if the application has enabled the silent update function, it will not perform a silent update on the current date, that is, it will not download the application update data from the server on the current date.

[0217] In some embodiments, although the application cannot be silently updated on the current date, users can still manually update the application.

[0218] As an example, after receiving an update message, the application can display an update notification when the user opens the application. In this case, if the application receives a confirmation of the update notification, it can send an application download request to the server, carrying the download address of the application's update data. After receiving the application download request, the server can obtain the update data based on the download address carried in the application download request and send the update data to the application. After receiving the update data, the application can update the application based on the update data.

[0219] Alternatively, the server can send the update data to the application via a CDN. This improves the reliability and stability of data transmission and increases the download speed of the update data.

[0220] Step 707: If the random number is within the target value range, the server determines one or more target times based on the bandwidth utilization and traffic price of each time period in the m days prior to the current date, where m is a positive integer.

[0221] The operation of step 707 is similar to that of step 307 above, and will not be described again in this embodiment.

[0222] Step 708: The server sends an application update message to the application.

[0223] For example, the application update message may carry the download address of the application's update data and a second instruction, which indicates that a silent update is allowed on the current date.

[0224] Furthermore, the application update message may also carry one or more target times, and optionally, the priority of each target time among multiple target times.

[0225] Optionally, the application update message may also carry version information of the updated version of the application, and / or configuration information, etc., which are not limited in this embodiment.

[0226] After receiving the application update message, the application can determine that a silent update is permitted on the current date based on the second indication information carried in the application update message. In this case, if the application update message does not carry a target time, the application can determine that a silent update is permitted throughout the current date; if the application update message carries a target time, the application can determine that a silent update is permitted during one or more target times within the current date.

[0227] In some embodiments, if the application update message does not carry a target time, then when the silent update function is enabled, if the application detects that the phone status meets preset conditions and the conditions indicated by the configuration information within the current date, it can send an application download request to the server. This application download request carries the download address of the application's update data. Upon receiving the application download request, the server can obtain the update data according to the download address and send the update data to the application. After receiving the update data, the application updates itself based on the update data.

[0228] The preset conditions can be set in advance. For example, the preset condition can be that the mobile phone is in a screen-off state; or, the preset condition can be that the mobile phone is in a screen-off state and the mobile phone is connected to WLAN; of course, the preset condition can also be other conditions, which are not limited in this embodiment.

[0229] In other embodiments, if the application update message carries one or more target times, then when the silent update function is enabled, if the application detects that the time difference between the current time and any one of the target times within the current date is less than or equal to a preset time, and detects that the phone status meets preset conditions and the conditions indicated by the configuration information, it can send an application download request to the server. This application download request carries the download address of the application's update data. Upon receiving the application download request, the server can obtain the update data according to the download address and send the update data to the application. After receiving the update data, the application updates itself based on the update data.

[0230] The preset duration can be set in advance. For example, the preset duration can be 3 minutes, 5 minutes, etc., but this application embodiment does not limit this.

[0231] It should be noted that in this embodiment of the application, the mobile phone may be instructed to have the right to silently update at one or more target times within the current date, while it may not be able to silently update at other times, thereby avoiding to some extent the situation of never updating the application and repeatedly updating the application.

[0232] For example, the server can send the updated data to the application via a CDN. This improves the reliability and stability of data transmission and increases the download speed of the updated data.

[0233] In some embodiments, if the silent update function in the application is not enabled, the application cannot perform silent updates, but the user can still manually update the application. The specific steps for this manual update can be found in the description of step 706, and will not be repeated here.

[0234] In this embodiment, after receiving an application update query request from an application on a mobile phone, if the server determines that the application needs an update, it maps the device identifier of the mobile phone to a random number within a preset value range. Based on the number of days between the preset date and the current date, and a target equal score (i.e., n), the server determines the target value range corresponding to the current date within the preset value range. If the random number is not within the target value range, the server prohibits the mobile phone from performing a silent update on the current date; if the random number is within the target value range, the server allows the mobile phone to perform a silent update on the current date. In this way, the silent updates that were originally scheduled for one day can be evenly distributed across n days, that is, the silent update traffic that was originally scheduled for one day can be scheduled across n days, achieving a uniform distribution of traffic. This not only improves the download speed during silent updates and enhances the user experience, but also allows for dynamic control of instantaneous bandwidth by dynamically adjusting silent update traffic, thereby avoiding excessive daily peak bandwidth and controlling CDN costs to a certain extent.

[0235] The following explains how to enable and disable the silent update feature in the settings application.

[0236] The Settings app is used to configure and manage various settings and parameters of your phone. For example, the Settings app can be used to configure and manage network settings, application management, display settings, security and privacy, system and updates, and more. Optionally, the System and Updates settings may include options or switches to enable or disable silent updates.

[0237] Generally, the silent update feature in the Settings app can be enabled or disabled by the user. If the user enables silent updates in the Settings app, the Settings app can automatically update the phone's operating system; if the user disables silent updates in the Settings app, the user can manually update the phone's operating system.

[0238] For example, with Figure 2 The process is similar. Users can open the Settings app on their phone and find the option or switch to turn the silent update function on or off in the Settings app interface. Users can turn the silent update function on or off in the Settings app by operating the corresponding option or switch.

[0239] Figure 8This is a flowchart illustrating an update control method provided in an embodiment of this application. The method is applied to a settings application and a server in a mobile phone. The server can be the server corresponding to the settings application, or optionally, the server of the mobile phone manufacturer. See also... Figure 8 The method includes the following steps:

[0240] Step 801: The Settings application on the phone sends a system update query request to the server.

[0241] For example, the system update query request may carry the device identifier of the mobile phone and the version number of the mobile phone's operating system. Of course, the system update query request may also carry other information, which is not limited in this embodiment.

[0242] The device identifier for the mobile phone has already been explained in step 301 above, and will not be repeated here.

[0243] The version number of an operating system indicates the version of the operating system. Generally, a larger version number indicates a newer version, and a smaller version number indicates an older version.

[0244] The system update query request is used to request whether an updated version of the operating system for the mobile phone exists.

[0245] In some embodiments, the settings application can periodically send system update query requests to the server to periodically check for the existence of an updated version of the phone's operating system. The frequency of these system update query requests can be preset. For example, the settings application can send system update query requests to the server every 30 minutes, 1 hour, or 2 hours.

[0246] Each time the server receives a system update query request sent by the settings application, it can execute steps 802 to 808 as follows.

[0247] Step 802: After receiving the system update query request, the server determines whether the operating system needs to be updated based on the operating system version number.

[0248] It should be noted that after developing a new version of the operating system, mobile phone manufacturers store it on a server. In this case, if the version number of the new operating system is less than the version number of the operating system stored on the server, it can be determined that the operating system needs to be updated; if the version number of the new operating system is greater than or equal to the version number of the operating system stored on the server, it can be determined that the operating system does not need to be updated.

[0249] Step 803: If the operating system needs to be updated, the server obtains the download address of the update data for the operating system.

[0250] The download address for the operating system's update data is used to indicate the storage location of the update data on the server.

[0251] Furthermore, the server can also obtain version information of the updated version of the operating system, such as size, version number, change log, etc., which is not limited in this embodiment of the application.

[0252] Optionally, if the operating system needs to be updated, the server can also obtain configuration information. This configuration information has already been described in step 303 above and will not be repeated here.

[0253] Step 804: The server maps the device identifier of the mobile phone to a random number within a preset value range.

[0254] The operation of step 804 is similar to that of step 304 above, and will not be described again in this embodiment.

[0255] Step 805: The server determines the target value range corresponding to the current date within the preset value range based on the number of days between the preset date and the current date, as well as the target equal score.

[0256] The operation of step 805 is similar to that of step 305 above, and will not be described again in this embodiment.

[0257] It should be noted that there is no strict order in which steps 804 and 805 are executed. That is, step 804 can be executed first and then step 805, or step 805 can be executed first and then step 804, or steps 804 and 805 can be executed in parallel.

[0258] If the random number mapped to the device identifier of the mobile phone within the preset value range is not within the target value range, the server prohibits the mobile phone from performing a silent update on the current date, and then executes step 806; if the random number is within the target value range, the server allows the mobile phone to perform a silent update on the current date, and then executes steps 807 to 808.

[0259] Step 806: If the random number is not within the target value range, the server sends a system update message to the settings application.

[0260] The operation of step 806 is similar to that of step 706 above, and will not be described again in this embodiment.

[0261] Step 807: If the random number is within the target value range, the server determines one or more target times based on the bandwidth utilization and traffic price of each time period in the m days prior to the current date, where m is a positive integer.

[0262] The operation of step 807 is similar to that of step 307 above, and will not be described again in this embodiment.

[0263] Step 808: The server sends a system update message to the settings application.

[0264] The operation of step 808 is similar to that of step 708 above, and will not be described again in this embodiment.

[0265] In this embodiment, after receiving a system update query request from the settings application on the mobile phone, if the server determines that the mobile phone's operating system needs an update, it maps the mobile phone's device identifier to a random number within a preset value range. Based on the number of days between the preset date and the current date, and a target equal score (i.e., n), the server determines the target value range corresponding to the current date within the preset value range. If the random number is not within the target value range, the server prohibits the mobile phone from performing a silent update on the current date; if the random number is within the target value range, the server allows the mobile phone to perform a silent update on the current date. In this way, the silent updates that were originally scheduled for one day can be evenly distributed across n days, that is, the silent update traffic that was originally scheduled for one day can be scheduled across n days, achieving a uniform distribution of traffic. This not only improves the download speed during silent updates and enhances the user experience, but also allows for dynamic control of instantaneous bandwidth by dynamically adjusting silent update traffic, thereby avoiding excessive daily peak bandwidth and controlling CDN costs to a certain extent.

[0266] The communication system involved in the embodiments of this application will be described below.

[0267] Figure 9 This is a schematic diagram of a communication system provided in an embodiment of this application. See also... Figure 9 The communication system may include a first device 901 and a second device 902.

[0268] The first device 901 and the second device 902 can communicate via wired or wireless connection.

[0269] There can be multiple second devices 902. Each second device 902 has an operating system and can have one or more applications installed.

[0270] For example, any second device 902 can be a mobile terminal (MT), mobile station (MS), mobile unit (MU), wireless unit, remote unit, user agent, mobile client, etc. For instance, any second device 902 can be a mobile phone, tablet computer, wearable device, digital camera, in-vehicle device, augmented reality (AR) device, virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), laptop computer, etc., and this application embodiment does not limit this.

[0271] The first device 901 may be a device storing an updated version of an operating system, and / or, storing an updated version of an application. For example, the first device 901 may be a server.

[0272] Optionally, the second device 902 may obtain update data of its operating system from the first device 901 and update its own operating system accordingly. And / or, the second device 902 may obtain update data of applications installed on the second device 902 from the first device 901 and update the applications accordingly.

[0273] For example, the first device 901 can transmit operating system update data and / or application update data to the second device 902 via CDN.

[0274] Figure 10 This is a flowchart of an update control method provided in an embodiment of this application. See also... Figure 10 The method includes the following steps:

[0275] Step 1001: The second device sends an update query request to the first device.

[0276] For example, the update query request could be the above. Figure 3 The application update query request described in the embodiments may be as described above. Figure 7 The application update query request described in the embodiments may be as described above. Figure 8 The system update query request described in the embodiment.

[0277] This update query request is used to check whether the second device needs an update.

[0278] If the update query request is as described above Figure 3 The application update query request described in the embodiment indicates that the second device has an update requirement, meaning that the application update query request contains a target application to be updated within the application identifiers of one or more applications. If the update query request is as described above... Figure 7 The application update query request described in the embodiment indicates that the application sending the application update query request needs to be updated; if the update query request is as described above... Figure 8 The system update query request described in the embodiment indicates that the second device has an update requirement, meaning that the operating system of the second device needs to be updated.

[0279] In some embodiments, the second device may periodically send update query requests to the first device to periodically check whether the second device has an update requirement. The period for the second device to send update query requests to the first device can be preset. For example, the second device may send update query requests to the first device every 30 minutes, 1 hour, or 2 hours.

[0280] Each time the first device receives an update query request sent by the second device, it can execute steps 1002 to 1008 as follows.

[0281] Step 1002: After receiving the update query request, if the first device determines that the second device has an update requirement, it maps the device identifier of the second device to a random number within a preset value range.

[0282] Optionally, if the second device needs to be updated, the first device can also obtain the download address of the update data.

[0283] Furthermore, the first device can also obtain version information of the updated data, such as size, version number, update log, etc., which is not limited in this embodiment of the application.

[0284] Optionally, if the second device requires an update, the first device can also obtain configuration information. This configuration information has already been described in step 303 above and will not be repeated here.

[0285] The operation of the first device mapping the device identifier of the second device to a random number within a preset numerical range is similar to the operation of step 304 above, and will not be described again in this embodiment.

[0286] Step 1003: The first device determines the target value range corresponding to the current date within the preset value range based on the number of days between the preset date and the current date, as well as the target equal score.

[0287] The operation of step 1003 is similar to that of step 305 above, and will not be described again in this embodiment.

[0288] If the random number mapped to the device identifier of the second device within the preset value range is not within the target value range, then proceed to step 1004; if the random number is within the target value range, then proceed to step 1005.

[0289] Step 1004: If the random number is not within the target value range, the first device prohibits the second device from performing a silent update on the current date.

[0290] For example, the operation of the first device to prevent the second device from making a silent update on the current date can be: the first device sends a first update message to the second device.

[0291] The first update message can be the application update message in step 306 above. In this case, the operation of the first device sending the first update message to the second device is similar to the operation in step 306 above, and will not be described again in this embodiment.

[0292] Alternatively, the first update message can be the application update message in step 706 above. In this case, the operation of the first device sending the first update message to the second device is similar to the operation in step 706 above, and this application embodiment will not repeat it here.

[0293] Alternatively, the first update message can be the system update message in step 806 above. In this case, the operation of the first device sending the first update message to the second device is similar to the operation in step 806 above, and this embodiment of the application will not repeat it here.

[0294] Step 1005: If the random number is within the target value range, the first device allows the second device to perform a silent update on the current date.

[0295] For example, if the random number is within the target value range, the first device can also determine one or more target times based on the bandwidth utilization and traffic price for each time period within each day of the m days preceding the current date. The specific operation is similar to the operation in step 307 above, and will not be described again in this embodiment.

[0296] For example, the operation by which the first device allows the second device to perform a silent update on the current date can be: the first device sends a second update message to the second device.

[0297] The second update message can be the application update message in step 308 above. In this case, the operation of the first device sending the second update message to the second device is similar to the operation in step 308 above, and will not be described again in this embodiment.

[0298] Alternatively, the second update message can be the application update message in step 708 above. In this case, the operation of the first device sending the second update message to the second device is similar to the operation in step 708 above, and this application embodiment will not repeat it here.

[0299] Alternatively, the second update message can be the system update message in step 808 above. In this case, the operation of the first device sending the second update message to the second device is similar to the operation in step 808 above, and this application embodiment will not repeat it here.

[0300] In this embodiment, after receiving an update query request from the second device, if the first device determines that the second device has an update requirement, it maps the device identifier of the second device to a random number within a preset value range. Based on the number of days between the preset date and the current date, and a target equalization value (i.e., n), the first device determines the target value range corresponding to the current date within the preset value range. If the random number is not within the target value range, the first device prohibits the second device from performing a silent update on the current date; if the random number is within the target value range, the first device allows the second device to perform a silent update on the current date. In this way, all silent updates originally scheduled for one day by the second device can be evenly distributed over n days, that is, all silent update traffic originally scheduled for one day by the second device can be scheduled over n days, achieving a uniform distribution of traffic. This not only improves the download speed during silent updates and enhances the user experience, but also allows for dynamic control of instantaneous bandwidth by dynamically adjusting silent update traffic, thereby avoiding excessive daily peak bandwidth and controlling CDN costs to a certain extent.

[0301] Figure 11 This is a schematic diagram of an update control device provided in an embodiment of this application. The device can be implemented as part or all of a computer device by software, hardware, or a combination of both. This computer device can be as described below. Figure 13 The device shown. See also Figure 11 The device includes: a receiving module 1101, a mapping module 1102, a determining module 1103, a prohibiting module 1104, and an enabling module 1105.

[0302] The receiving module 1101 is used to receive the update query request sent by the second device;

[0303] The mapping module 1102 is used to map the device identifier of the second device to a random number within a preset value range if it is determined that the second device has an update requirement.

[0304] The determination module 1103 is used to determine the target value range corresponding to the current date within the preset value range based on the number of days between the preset date and the current date and the target equal division value. The target value range is one of the parts obtained after dividing the preset value range into n equal parts, where n is the target equal division value and n is an integer greater than or equal to 2.

[0305] The disable module 1104 is used to disable the second device from performing a silent update on the current date if the random number is not within the target value range.

[0306] The allow module 1105 is configured to allow the second device to perform a silent update on the current date if the random number is within the target value range.

[0307] In this embodiment, after receiving an update query request from the second device, if the update control device determines that the second device has an update requirement, it maps the device identifier of the second device to a random number within a preset value range. It then determines the target value range corresponding to the current date within the preset value range based on the interval between the preset date and the current date and the target equal score (i.e., n). If the random number is not within the target value range, the first device prohibits the second device from performing a silent update on the current date; if the random number is within the target value range, the first device allows the second device to perform a silent update on the current date. In this way, all silent updates that were originally scheduled for one day by the second device can be evenly distributed over n days, that is, all silent update traffic that was originally scheduled for one day by the second device can be scheduled over n days, achieving a uniform distribution of traffic. This not only improves the download speed during silent updates and enhances the user experience, but also allows for dynamic control of instantaneous bandwidth by dynamically adjusting silent update traffic, thereby avoiding excessive daily peak bandwidth to a certain extent and achieving the goal of controlling CDN costs.

[0308] It should be noted that the update control device provided in the above embodiments is only illustrated by the division of the above functional modules when updating. In actual applications, the above 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.

[0309] The functional units and modules in the above embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of the embodiments of this application.

[0310] The update control device and update control method embodiments provided in the above embodiments belong to the same concept. The specific working process and technical effects of the units and modules in the above embodiments can be found in the method embodiment section, and will not be repeated here.

[0311] Figure 12 This is a schematic diagram of the structure of a first device provided in an embodiment of this application. See also... Figure 12 The first device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 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, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0312] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the first device. In other embodiments of this application, the first device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0313] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, memory, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0314] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from this memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves system efficiency.

[0315] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the first device. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions, such as saving music, video, and other files on the external storage card.

[0316] Internal memory 121 can be used to store computer-executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of the first device by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback, image playback, etc.), etc. The data storage area may store data created by the first device during use (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

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

[0318] The mobile communication module 150 can provide solutions for wireless communication applications on the first device, including second-generation mobile networks (2G), third-generation mobile networks (3G), fourth-generation mobile networks (4G), and fifth-generation mobile networks (5G).

[0319] The wireless communication module 160 can provide solutions for wireless communication applications on the first device, including WLAN (such as Wi-Fi networks), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and other wireless communication technologies.

[0320] The first device can realize audio functions, such as music playback and recording, through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, and an application processor.

[0321] The first device can achieve shooting functions through an ISP, camera 193, video codec, GPU, display 194, and application processor.

[0322] The first device implements display functionality through a GPU, a display screen 194, and an application processor.

[0323] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a minimized display, a micro-led display, a micro-oled display, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the first device may include one or N displays 194, where N is an integer greater than 1.

[0324] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. Touch sensor 180K can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of the first device, in a different position than display screen 194.

[0325] Figure 13 This is a schematic diagram of the structure of a second device provided in an embodiment of this application. See also... Figure 13 The second device includes at least one processor 201, a communication bus 202, a memory 203, and at least one communication interface 204.

[0326] The processor 201 may be a microprocessor (including a central processing unit (CPU) or the like), an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0327] The communication bus 202 may include a path for transmitting information between the aforementioned components.

[0328] The memory 203 may be a read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), optical disc (including compact disc read-only memory (CD-ROM), compressed optical disc, laser disc, digital versatile optical disc, Blu-ray disc, etc.), magnetic disk storage medium, or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 203 may exist independently and be connected to the processor 201 via the communication bus 202. The memory 203 may also be integrated with the processor 201.

[0329] Communication interface 204 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), WLAN, etc.

[0330] In a specific implementation, as one example, the processor 201 may include one or more CPUs, such as... Figure 13 CPU0 and CPU1 are shown in the diagram.

[0331] In a specific implementation, as one example, the second device may include multiple processors, such as... Figure 13 The processors 201 and 205 are shown. Each of these processors may be a single-core processor or a multi-core processor. Here, "processor" may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0332] The memory 203 stores program code 206 for executing the scheme of this application, and the processor 201 executes the program code 206 stored in the memory 203. The second device can implement the update control method provided in the above embodiment through the processor 201 and the program code 206 in the memory 203.

[0333] This application does not specifically limit the structure of the execution subject of the update control method. As long as the code containing the update control method provided in this application is executed, processing can be performed according to the update control method provided in this application. For example, the execution subject of the update control method provided in this application can be a functional module in a computer device that can call and execute programs, or it can be a processing device applied in a computer device, such as a chip.

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

[0335] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0336] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.

[0337] This application also provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0338] This application also provides a chip system including a processor coupled to a memory. The processor executes a computer program stored in the memory to implement the steps of any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0339] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic cable, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (such as floppy disks, hard disks, magnetic tapes, etc.), optical media (such as Digital Versatile Discs (DVDs), etc.) or semiconductor media (such as Solid State Disks (SSDs), etc.).

[0340] The above-described embodiments are optional embodiments provided by this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the technical scope disclosed in this application should be included within the protection scope of this application.

Claims

1. An update control method, characterized in that, Applied to a first device, the method includes: Receive update query requests sent by the second device; If it is determined that the second device has an update requirement, the hash value of the device identifier of the second device is obtained, and the hash value is used as a random number seed to initialize the random number generator. The initialized random number generator generates a random number within a preset value range. The target remainder is obtained by taking the remainder after dividing the number of days between the preset date and the current date by the target equal score. The target value range corresponding to the current date within the preset value range is determined based on the target remainder. The target value range is one of the parts obtained by dividing the preset value range into n equal parts, where n is the target equal part value and n is an integer greater than or equal to 2. If the random number is not within the target value range, the second device is prohibited from silently updating on the current date; If the random number is within the target value range, the second device is allowed to perform a silent update on the current date.

2. The method as described in claim 1, characterized in that, The preset numerical range includes 100 consecutive integers.

3. The method as described in claim 1 or 2, characterized in that, Before performing a modulo operation on the number of days between the preset date and the current date and the target equal fraction to obtain the target remainder, the method further includes: The value obtained by dividing 1 by a preset ratio is rounded up to obtain the target score.

4. The method as described in claim 1, characterized in that, Determining the target value range corresponding to the current date within the preset value range based on the target remainder includes: The target numerical range is determined to be the (i+1)th part obtained by dividing the preset numerical range n into equal parts, where i is the target remainder.

5. The method as described in claim 1, characterized in that, The preset numerical range includes integers from 0 to 99; Before performing a modulo operation on the number of days between the preset date and the current date and the target equal fraction to obtain the target remainder, the method further includes: Divide 100 by the target equal division value and round up to obtain the target average. Determining the target value range corresponding to the current date within the preset value range based on the target remainder includes: The target value range is defined as the range within the preset value range that is greater than or equal to i times the target average and less than i+1 times the target average, where i is the target remainder.

6. The method as described in claim 1, characterized in that, Before performing a modulo operation on the number of days between the preset date and the current date and the target equal fraction to obtain the target remainder, the method further includes: Divide 100 by the target equal division value and round up to obtain the target average. Divide the target average by 100 to obtain the target average proportion; Determining the target value range corresponding to the current date within the preset value range based on the target remainder includes: The range that is greater than i times the target average ratio and less than or equal to i+1 times the target average ratio is defined as the target ratio range, where i is the target remainder; The target numerical range is defined as the numerical range corresponding to the target ratio range within the preset numerical range.

7. The method as described in any one of claims 1 to 6, characterized in that, After determining the target value range corresponding to the current date within the preset value range based on the target remainder, the method further includes: If the random number is within the target value range, then one or more target times are determined based on the bandwidth utilization and traffic price of each time period in the m days preceding the current date, where m is a positive integer, and the target time is the time during which the second device is allowed to perform silent updates within the current date.

8. The method as described in claim 7, characterized in that, The process of determining one or more target times based on bandwidth utilization and traffic prices for each time period within each day of the m days preceding the current date includes: Divide the bandwidth utilization rate of each time period within each day of the m days by the traffic price to obtain the unit bandwidth utilization rate of each time period within each day of the m days. Based on the unit bandwidth utilization rate of each time period within each day of the m days, determine the estimated unit bandwidth utilization rate of each time period within the current date; Obtain the average unit bandwidth utilization rate of the estimated unit bandwidth utilization rate for each time period within the current date; The one or more target times are determined based on the average unit bandwidth utilization.

9. The method as described in claim 8, characterized in that, Determining the one or more target times based on the average unit bandwidth utilization includes: From the time periods following the current time within the current date, identify one or more target time periods where the estimated unit bandwidth utilization is less than the average unit bandwidth utilization; The start time of each target time period in at least one of the one or more target time periods is determined as the target time.

10. The method as described in claim 8, characterized in that, Determining the one or more target times based on the average unit bandwidth utilization includes: Divide the bandwidth utilization rate at the current time by the traffic price at the current time to obtain the actual bandwidth utilization rate per unit at the current time. If the actual unit bandwidth utilization rate at the current time is less than the average unit bandwidth utilization rate, then the current time is determined as the target time; If the actual unit bandwidth utilization rate at the current time is greater than or equal to the average unit bandwidth utilization rate, then one or more target time periods with estimated unit bandwidth utilization rates less than the average unit bandwidth utilization rate are determined from the various time periods after the current time within the current date, and the start time of each target time period in at least one of the one or more target time periods is determined as the target time.

11. The method according to any one of claims 1 to 10, characterized in that, The prohibition of the second device from performing silent updates on the current date includes: Send a first update message to the second device. The first update message carries the download address of the update data and a first indication information. The first indication information is used to indicate that silent updates are prohibited on the current date. The provision allowing the second device to perform a silent update on the current date includes: A second update message is sent to the second device. The second update message carries the download address of the update data and second indication information, which is used to indicate that a silent update is allowed on the current date.

12. A computer device, characterized in that, The computer device includes: one or more processors, and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the computer device to perform the method as described in any one of claims 1 to 11.

13. A chip system, characterized in that, The chip system is applied to a computer device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the computer device to perform the method as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on a computer device, cause the computer device to perform the method as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, When the computer program product is run on a computer device, the computer device performs the method as described in any one of claims 1 to 11.

Images