Application pre-installation method and related apparatus
By working collaboratively between terminal devices and servers and utilizing a blacklist-style application list, pre-installation of applications for different user groups was achieved. This solved the problems of long system upgrade times and high costs for terminal devices, and improved user experience and application fit.
Patent Information
- Application Number
- PCT/CN2025/107043
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-07-08
- Filing Date
- 2025-07-04
- Publication Date
- 2026-01-15
AI Technical Summary
When upgrading a system, terminal devices may encounter issues such as downloaded applications not being compatible with the user, high costs associated with building system upgrade installation packages, and long upgrade times.
By obtaining the first upgrade package, a message is sent to the server to determine the list of applications to be installed. The application list returned by the server is used to determine which applications to install or not to install. The terminal device installs the corresponding applications according to the list. By using a blacklist approach, data interaction and server traffic pressure are reduced, and applications can be pre-installed for different user groups.
It reduces the time and development cost of OTA upgrades for terminal devices, improves the fit of application installation, and enhances user experience and application activation rate.
Smart Images

Figure CN2025107043_15012026_PF_FP_ABST
Abstract
Description
Pre-installation application methods and related devices
[0001] This application claims priority to Chinese Patent Application No. 202410909974.5, filed on July 8, 2024, entitled “Method and Apparatus for Pre-installation Application”, the entire contents of which are incorporated herein by reference. Technical Field
[0002] This application relates to the field of terminals, and more particularly to methods and related devices for pre-installing applications. Background Technology
[0003] Applications can be installed on terminal devices during system upgrades. However, issues such as downloaded applications not being tailored to the user, high costs of building system upgrade installation packages, and long system upgrade times exist. Therefore, providing user-friendly applications, reducing the cost of building system upgrade installation packages, and shortening system upgrade time have become urgent problems to be solved. Summary of the Invention
[0004] This application provides a method and related apparatus for pre-installing applications based on different user groups. When different terminal devices are upgraded over the air (OTA), different applications can be installed based on the user tags of different terminal devices.
[0005] Firstly, a method for installing applications is provided, applied to an electronic device. The method includes: obtaining a first upgrade package, which includes installation packages for N applications; sending a first message to a server, the first message determining M applications from the N applications identified on the server, where M is less than or equal to N, and M and N are positive integers; receiving a first application list returned by the server, which includes the M applications; if the first application list is a whitelist, installing the M applications according to the first application list; if the first application list is a blacklist, installing the NM applications according to the first application list. The first upgrade package can be an OTA upgrade package, whereby the OTA upgrade package downloaded by the electronic device carries multiple application installation packages. This OTA upgrade package is an installation package of a first operating system with multiple application installation packages added. The application installation packages are compressed and added to the OTA upgrade package. The electronic device can obtain the application installation packages simultaneously with downloading the OTA upgrade package, eliminating the need to download the application installation packages separately after downloading the OTA upgrade package, thus reducing the time spent on OTA upgrades and making the construction of OTA upgrade packages more convenient. Among them, applications include pre-installed applications, which can be applications pre-installed in electronic devices.
[0006] Different electronic devices can receive different application lists, which can then instruct the devices to install different applications. For a given electronic device, the applications installed can be tailored to its user. For example, if the user enjoys listening to music and has a music playback application A, the device can pre-install a music playback application B, providing the user with more application options.
[0007] Different electronic devices can be devices of the same model (such as mobile phones of the same model) or devices of different models (such as mobile phones of different models). This application does not limit this.
[0008] The server can record the M applications that need to be installed on electronic devices. This record can be in the form of a blacklist or a whitelist. However, since the number of installed applications on electronic devices is generally greater than the number of uninstalled applications, a blacklist would require recording fewer applications than a whitelist. Therefore, a blacklist is typically used, recording the number of uninstalled applications. This reduces data exchange between the device and the cloud, as well as the number of queries during application installation on the device, thus reducing the traffic pressure on the server during centralized upgrades of electronic devices.
[0009] In conjunction with the first aspect, the first upgrade package downloaded by the electronic device includes a first identifier, and the electronic device sends a first message to the server, including: sending a first message to the server based on the first identifier.
[0010] Before sending the first message, the electronic device needs to confirm whether pre-installation for a specific user group is enabled. After confirming that pre-installation for that user group is enabled, the electronic device then sends the first message to the server to retrieve the list of first pre-installed applications for that user group.
[0011] In conjunction with the first aspect, in some embodiments of the first aspect, the first message further includes a first version, which is the version of the first upgrade package, and the first version is used to instruct the server to determine the N applications based on the first version.
[0012] The server that retrieves N application installation packages for the electronic device is different from the server that retrieves the first application list. Before obtaining the version number of the upgrade package, the server retrieving the first application list can store multiple sets of N applications, and it cannot determine which set of N applications the electronic device has downloaded. Therefore, after obtaining the first version, this server can determine the specific N applications downloaded by the electronic device, allowing subsequent servers to determine the applications the electronic device needs to install from the corresponding N applications.
[0013] In conjunction with the first aspect, in some embodiments of the first aspect, the first message includes a first user identifier, which is used by the server to identify the M applications associated with the first user identifier.
[0014] The first user identifier may include a unique device identifier (UDID). The server stores the mapping between UDIDs and user tags, and also stores the relationship between the user tag and the applications installed on the electronic device. Thus, the server can obtain the user tag based on the UDID, and ultimately obtain the installed applications corresponding to the user tag, such as the M applications mentioned above.
[0015] In conjunction with the first aspect, in some embodiments of the first aspect, the method further includes: displaying an application icon or application card of a first application on a first interface, wherein the M applications include the first application.
[0016] In this way, electronic devices can display the installed applications or service cards on the interface, allowing users to directly experience the effect of application installation tailored to different user groups.
[0017] It should be noted that, in the absence of conflict, the features in the various embodiments of the first aspect can be combined with each other, and any combination of features in different embodiments is also within the protection scope of this application. That is to say, the various embodiments described above can also be arbitrarily combined according to actual needs.
[0018] Secondly, a method for installing applications is provided. This method is applied to a server and includes: receiving a first message sent by an electronic device; determining a first application list, wherein the first message is used to determine M applications out of N applications, where the N applications are applications corresponding to a first upgrade package obtained by the electronic device, and M is less than or equal to N, and M and N are positive integers; returning the first application list to the electronic device, the first application list including the M applications, wherein if the first application list is a whitelist, it is used to instruct the electronic device to install the M applications, and if the first application list is a blacklist, it is used to instruct the electronic device to install the NM applications. Thus, the server receives a request from the electronic device to obtain the first application list, determines the applications installed by the electronic device, and generates the first application list based on the installed applications. The server can return the first application list to the electronic device to instruct the electronic device to install specified applications. The first application list can be a blacklist or a whitelist. However, since the number of applications installed on an electronic device is generally greater than the number of applications not installed, a blacklist approach is usually used, recording the number of applications not installed in the list. This reduces the communication data between the server and the electronic device, and reduces the traffic pressure on the server when electronic devices are undergoing concentrated upgrades.
[0019] In conjunction with the second aspect, in some embodiments of the second aspect, the first upgrade package includes a first identifier.
[0020] The first user identifier includes the UDID. This allows the server to obtain the applications installed on the electronic device using the UDID.
[0021] In conjunction with the second aspect, in some embodiments of the second aspect, the first message further includes a first version, which is the version of the first upgrade package, and the method includes: determining the N applications based on the first version.
[0022] In this way, the server has a correspondence between upgrade package versions and application selection ranges, so it is possible to determine which applications to select for installation by obtaining the upgrade package version.
[0023] In conjunction with the second aspect, in some embodiments of the second aspect, the first message includes a first user identifier, and the method includes: identifying the M applications associated with the first user identifier.
[0024] In this way, the server can obtain the audience tag based on the UDID, and finally obtain the installed applications corresponding to the audience tag, such as the M applications.
[0025] In conjunction with the second aspect, in some embodiments of the second aspect, the server stores the user tags of the electronic device, and the server sets a correspondence between the user tags and the applications installed on the electronic device; determining the M applications through the first user identifier includes: obtaining the user tags of the electronic device through the first user identifier, and determining the M applications corresponding to the user tags.
[0026] It should be noted that, in the absence of conflict, the features in the various embodiments of the second aspect can be combined with each other, and any combination of features in different embodiments is also within the scope of protection of this application. That is to say, the various embodiments described above can also be arbitrarily combined according to actual needs.
[0027] Thirdly, a method for installing applications is provided. This method is applied to a first communication system, which includes an electronic device and a server. The method includes: the electronic device acquiring a first upgrade package, which includes installation packages for N applications; the server receiving a first message sent by the electronic device to determine a first application list, the first message being used to determine M applications from the N applications, where M is less than or equal to N, and M and N are positive integers; the server returning the first application list to the electronic device, the first application list including the M applications; if the first application list is a whitelist, the server installing the M applications according to the first application list; if the first application list is a blacklist, the server installing the NM applications according to the first application list.
[0028] In conjunction with the third aspect, the first upgrade package downloaded by the electronic device includes a first identifier, and the electronic device sends a first message to the server, specifically including: the electronic device sending a first message to the server based on the first identifier.
[0029] In conjunction with the third aspect, in some implementations of the third aspect, the first message further includes a first version, which is the version of the first upgrade package, and the method includes: the server determining the N applications based on the first version.
[0030] In conjunction with the third aspect, in some embodiments of the third aspect, the first message further includes a first version, which is the version of the first upgrade package. After the server receives the first message sent by the electronic device, the method further includes: the server identifying the M applications through the first user identifier, the M applications being associated with the first user identifier.
[0031] In conjunction with the third aspect, in some embodiments of the third aspect, the server stores the user tags of the electronic device, and the server sets a correspondence between the user tags and the applications installed on the electronic device; the server determines the M applications through the first user identifier, including: the server obtains the user tags of the electronic device through the first user identifier and determines the M applications corresponding to the user tags.
[0032] The first user identifier can be a UDID. The server stores the mapping between user tags and UDIDs, as well as the mapping between user tags and applications installed on electronic devices. In this way, the server can provide different installed applications based on different user tags.
[0033] In conjunction with the third aspect, in some embodiments of the third aspect, the first communication system further includes: a first server, the first server storing tags, the tags being user tags for electronic devices, the server setting a correspondence between the tags and applications installed on the electronic devices; after the server receives a first message sent by the electronic device, the method further includes: the server sending the first user identifier to the first server, the first server determining a first tag corresponding to the first user identifier from the tags, the first tag being a user tag for the electronic device; the server receiving the first tag returned by the first server, determining the M applications corresponding to the first tag.
[0034] In this way, electronic devices belonging to different user groups can receive different application lists, which can then instruct the electronic devices to install different applications. For a given electronic device, the applications installed can be tailored to the user of that device. For example, if the user of an electronic device enjoys listening to music and has a music playback application A, then the electronic device can pre-install a music playback application B, providing the user with more application options.
[0035] In conjunction with the third aspect, in some embodiments of the third aspect, the electronic device displays an application icon or application card of a first application on a first interface, wherein the M applications include the first application.
[0036] It should be noted that, in the absence of conflict, the features in the various embodiments of the third aspect can be combined with each other, and any combination of features in different embodiments is also within the scope of protection of this application. That is to say, the multiple embodiments described above can also be arbitrarily combined according to actual needs.
[0037] Fourthly, a method for installing applications is provided. This method is applied to a server where operators can configure the mapping between user tags and applications through the server's user interface. Operators can add policies for mapping user tags to applications within the server's user interface. These policies include the policy name, the device signal of the policy application, the policy batch, and the version number of the first installation package corresponding to the policy. In the configuration interface, operators can select whether an application should be installed for the specified user tags in a selection box, and can also configure the user tags corresponding to the applications in a selection bar. The server can obtain the first user identifier of the electronic device and send it to a first server. The first server stores the user tags corresponding to the first user identifier, which are designated as the first tag. The server obtains the first tag returned by the first server and, based on the mapping between user tags and applications configured by the operators, determines the M applications corresponding to the first tag.
[0038] In this way, operators can configure the server through a graphical interface to obtain the applications that can be installed on electronic devices. During specific periods (such as holidays), the applications installed corresponding to the user tags of electronic devices can change. Operators can adjust the mapping between user tags and applications in a timely manner and configure various installation strategies. For example, during holidays, operators can configure applications such as travel apps, online shopping apps, and entertainment apps with various user tags to promote these applications to more users on different electronic devices.
[0039] Fifthly, a method for installing applications is provided. In this second server, operators can configure whether to enable the first identifier of the first upgrade package through the server's interface. The second server's interface has a first option to enable or disable the mapping between user tags and applications. The server and / or the second server monitors network traffic. When the traffic on the server exceeds a threshold, operators can modify the first option on the second server to disable the first identifier. After the electronic device detects that the first identifier is disabled, it will install the installation packages for all N applications in the first upgrade package.
[0040] The second server can serve as the terminal publishing center server to prevent server traffic from exceeding thresholds. This avoids issues like lag or even malfunctions caused by excessive network traffic to the server during over-the-air upgrades of devices across the network.
[0041] A sixth aspect provides an electronic device including one or more memories and one or more processors; the memory is coupled to the one or more processors, the memory being used to store computer program code including computer instructions, the one or more processors calling the computer instructions to cause the electronic device to perform methods as described in the first aspect and some embodiments thereof.
[0042] In a seventh aspect, a server is provided, including at least one processor coupled to at least one memory, the at least one processor being configured to read a computer program stored in the at least one memory to perform a method as described in some embodiments of the second aspect and the second aspect.
[0043] Eighthly, a communication system is provided, including an electronic device and a server, the electronic device having a communication connection with the server, the electronic device performing a method as described in the third aspect and some embodiments thereof, and the server performing a method as described in the third aspect and some embodiments thereof.
[0044] A ninth aspect provides a computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement a method as described in the first aspect and some embodiments thereof, or a method as described in the second aspect and some embodiments thereof, or a method as described in the third aspect and some embodiments thereof.
[0045] In a tenth aspect, a computer device is provided, including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement a method as described in the first aspect and some embodiments of the first aspect, or a method as described in the second aspect and some embodiments of the second aspect, or a method as described in the third aspect and some embodiments of the third aspect.
[0046] Eleventhly, a computer program product is provided, including computer instructions that, when executed by a processor, implement the method as described in the first aspect and some embodiments of the first aspect, or the method as described in the second aspect and some embodiments of the second aspect, or the method as described in the third aspect and some embodiments of the third aspect.
[0047] In a twelfth aspect, a chip is provided that stores a computer program, which, when executed by the chip, implements the methods as described in the first aspect and some embodiments thereof, or the methods as described in the second aspect and some embodiments thereof, or the methods as described in the third aspect and some embodiments thereof. Attached Figure Description
[0048] Figure 1A is a flowchart of a pre-installation application method provided in this application;
[0049] Figure 1B is a flowchart of another pre-installation application method provided in this application;
[0050] Figure 1C is a flowchart of another pre-installation application method provided in this application;
[0051] Figures 2A-2E are schematic diagrams illustrating the effects of the pre-installation application method for different user groups provided in the embodiments of this application.
[0052] Figure 3A is a schematic diagram of the system architecture for pre-installed applications for different user groups provided in an embodiment of this application;
[0053] Figure 3B is a flowchart of the system-side method for pre-installing applications for different user groups provided in an embodiment of this application.
[0054] Figure 4 is a flowchart of cloud-based crowd tag creation provided in an embodiment of this application;
[0055] Figure 5 is a flowchart of the cloud-side configuration of a pre-installed application list and the mapping of user tags provided in an embodiment of this application;
[0056] Figure 6 is a schematic diagram of the pre-installed strategy management list for different user groups provided in an embodiment of this application;
[0057] Figure 7 is a schematic diagram of the pre-installation strategy configuration for different user groups provided in an embodiment of this application;
[0058] Figure 8A is a flowchart of obtaining pre-installed applications that meet user needs on the terminal side according to an embodiment of this application;
[0059] Figure 8B is a flowchart of cloud-based audience tag matching provided in an embodiment of this application;
[0060] Figure 9 is a flowchart illustrating how the cloud-side platform improves robustness to surge traffic according to an embodiment of this application.
[0061] Figure 10 is a schematic diagram of cloud-based blacklist generation provided in an embodiment of this application;
[0062] Figure 11 is a schematic diagram showing whether the cloud-side pre-installation package provided in the embodiment of this application has the ability to pre-install packages for different user groups;
[0063] Figure 12 is a schematic diagram of the end-side matching pre-installed application list provided in an embodiment of this application;
[0064] Figure 13 is a hardware architecture block diagram of the terminal device provided in the embodiment of this application. Detailed Implementation
[0065] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be a limitation of this application.
[0066] Devices can be upgraded using Over-The-Air (OTA) technology, and applications can be installed during the upgrade process. However, different users have different needs for the installed applications. For example, users who frequently listen to music need music search and playback software, while users who frequently engage in online communication need online community software. Content providers (CPs) of the applications need to promote them to suitable target groups (i.e., pre-install applications for specific demographics) to improve the activation and usage rates of the application after installation.
[0067] Regarding the question of how to pre-install applications for different user groups, Figures 1A to 1C show flowcharts of three pre-installation application methods, as detailed below:
[0068] Figure 1A illustrates a method flow for pre-installing an application. It includes the following 7 steps:
[0069] 1. The business terminal sends a request for pre-installed application data.
[0070] 2. The server sends pre-installation information, application file download address, and tracking file download address.
[0071] Before the application is pre-installed on the user's terminal device (user terminal), the pre-installation business operations personnel update the designated pre-installation information on the server. This pre-installation information includes information such as the OTA upgrade package version, the user terminal device model, and the user terminal device OTA upgrade customization information.
[0072] 3. The business terminal sends download requests to the application file download address and the tracking file download address.
[0073] 4. The server returns the application file and trace file.
[0074] 5. On the business terminal side, pre-installed files (such as version, model, and customization information), application files, and tracking files are packaged into a ROM package.
[0075] The pre-installation service operator sends a request to the server sequentially to obtain pre-installed application data and an application file download request from the service terminal. That is, the pre-installation service operator downloads the application installation package based on the pre-installation information and packages the obtained pre-installation files and application files into a read-only memory (ROM) package.
[0076] 6. The service terminal sends the ROM package to the terminal.
[0077] 7. When the user terminal is powered on for the first time, the ROM package is loaded, and the received application files and tracking files are installed on the terminal based on the pre-installed information.
[0078] The service terminal sends the ROM package to the user terminal. The user terminal downloads the ROM package and installs the pre-installed application software from the ROM package upon first power-on. The user terminal stores the downloaded ROM package in its ROM.
[0079] This solution allows user terminal devices to ship without pre-installing software. User terminal devices can download a ROM package and obtain pre-installed information and applications upon first power-on.
[0080] However, the scheme shown in Figure 1A has the following problems:
[0081] Firstly, this solution is only applicable to scenarios where the user terminal device is installed when it is first powered on, and cannot be continuously updated for the user terminal device during subsequent online operations.
[0082] Secondly, pre-installed business operators cannot predict the characteristics of users on different user terminal devices, resulting in a lack of information matching different users in customized information. When installing applications on user terminal devices, they do not have the ability to pre-install applications for different groups of people, and they are not close to consumers.
[0083] Figure 1B illustrates another method flow for pre-installing applications. It includes the following 13 steps:
[0084] 1. The operations staff sends the mapping between the configured UI theme and the list of pre-installed applications to the cloud.
[0085] 2. Configure application pools in the cloud.
[0086] The installation packages of pre-installed applications are stored in the cloud. Pre-installed business operators can configure the mapping relationship between the user interface (UI) theme and the list of pre-installed applications in the cloud.
[0087] 3. When a user powers on their terminal for the first time, they select a theme.
[0088] 4. The user terminal retrieves the list of applications corresponding to the theme from the cloud and downloads and installs them.
[0089] 5. The cloud returns the application software package to the user terminal.
[0090] 6. Install the application on the user terminal.
[0091] When a user terminal starts up for the first time, it will guide the user to select a UI theme. Each UI theme corresponds to a list of pre-installed applications. After the user selects a UI theme, the terminal will download and install the corresponding pre-installed application during the initial boot process.
[0092] 7. The user switches the UI theme multiple times on the user terminal.
[0093] 8. The user terminal sends information about the topics the user prefers to the cloud.
[0094] 9. The cloud-based system modifies the list of pre-installed applications based on the user's selected theme.
[0095] Subsequently, when the user terminal detects that the user has switched UI themes, the user terminal will update the user's list of pre-installed applications in the cloud according to the theme switched by the user.
[0096] 10. The user submits an OTA upgrade request to the user terminal.
[0097] 11. The user terminal sends an OTA upgrade request to the cloud.
[0098] 12. The cloud sends pre-installed application packages that match the user to the user's terminal.
[0099] 13. Adding or deleting pre-installed applications on user terminals.
[0100] When a user terminal detects an OTA upgrade request, it will retrieve the updated list of pre-installed applications from the cloud and add or delete pre-installed applications on the user terminal.
[0101] This solution uses a technique of binding a UI theme to a list of pre-installed applications, enabling it to pre-install applications for different user groups.
[0102] However, the scheme shown in Figure 1B has the following problems:
[0103] Firstly, this solution binds the pre-installed application list to the UI theme. When building OTA upgrade packages in the cloud, it is necessary to maintain consistency with the user's UI theme, resulting in high communication costs between the cloud and the user's terminal. Furthermore, the number of UI themes is limited, and the types of pre-installed applications corresponding to each UI theme are also limited.
[0104] Secondly, when user terminals undergo OTA upgrades, pre-installed applications are deleted based on the pre-installed application list, which affects the user experience.
[0105] Thirdly, this solution will download the pre-installed application installation package separately during the user terminal initialization and OTA upgrade process, resulting in slow user terminal initialization or OTA upgrade speed.
[0106] Figure 1C illustrates another method flow for pre-installing applications. It includes the following nine steps:
[0107] 1. Operators register and publish applications on the platform.
[0108] 2. The platform stores application files and file information in the cloud.
[0109] 3. Operations personnel customize pre-installed application strategies on the platform side, including application lists and application layouts.
[0110] 4. The platform builds and stores OTA packages on the cloud side.
[0111] The pre-installation service operators store customized application information on the platform side and store the installation packages of pre-installed applications in the cloud.
[0112] When the pre-installed service operators build OTA packages on the platform side, they will pack customized layout files and customized pre-installed application lists into the OTA package according to business needs, and store the OTA package in the cloud.
[0113] 5. The user clicks the OTA upgrade request on the user terminal.
[0114] 6. The user terminal initiates an OTA upgrade request to the cloud.
[0115] After a user terminal starts up for the first time or receives an OTA upgrade request, it can download the OTA package from the cloud.
[0116] 7. The cloud returns an OTA package to the user terminal, including customized application information and application layout files.
[0117] 8. User terminals download pre-installed application files via the cloud.
[0118] The user terminal downloads the installation packages of the pre-installed applications from the cloud based on the customized list of pre-installed applications in the OTA package.
[0119] 9. The user terminal reads the layout file and installs the pre-installed application.
[0120] User terminals can install the pre-installed application based on the layout file in the OTA package.
[0121] This solution employs a technical approach of adding pre-installed applications during OTA upgrades. The platform stores pre-installed information through a list of pre-installed applications and layout files, deploying the capability to customize pre-installed applications in the cloud, thereby enabling online operation of customized pre-installed applications.
[0122] However, the scheme shown in Figure 1C has the following problems:
[0123] Firstly, this solution lacks the ability to analyze user characteristics. The pre-installed applications on user terminals are only applicable to scenarios where customized applications are distributed, and are not tailored to consumers. Furthermore, the list of pre-installed applications to be installed depends on individual customization by the pre-installation business operations personnel, resulting in a limited variety of installation packages for pre-installed applications.
[0124] Secondly, during the OTA upgrade process, user terminals download the installation packages of pre-installed applications separately, which makes the OTA upgrade process take a long time.
[0125] In summary, the technical solution of adding pre-installed applications during OTA upgrades suffers from problems such as pre-installed applications not being tailored to consumers, high costs in building OTA upgrade packages, and long OTA upgrade times. To address these issues, this application provides a method and related apparatus for pre-installing applications based on user groups. This method allows different users' devices to install different pre-installed applications during terminal device upgrades, achieving the effect of segmented pre-installation and thus improving the user experience. Specifically, segmented pre-installed applications can match user preferences, increasing the frequency of application use and boosting application activation and usage rates.
[0126] The following uses Figures 2A to 11 to describe the method and related apparatus for pre-installing applications for different user groups provided in the embodiments of this application.
[0127] As shown in Figures 2A-2E, these figures illustrate the effects of the pre-installation method for different user groups.
[0128] Figure 2A shows the display interface of the terminal device before an OTA upgrade. This interface is the display interface of the terminal device without any applications installed. No application or service cards are displayed in this interface. Service cards are a form of application display page content, where application content can be placed on card-style icons.
[0129] After an over-the-air (OTA) upgrade, a terminal device can be pre-installed with an application. This application can be a general-purpose application (such as a memo app, Huawei Innovation Research app, or sports and health app). General-purpose applications can be provided by the terminal device manufacturer.
[0130] After an OTA (Over-The-Air) upgrade, terminal devices can also be pre-installed with third-party applications (such as Gaode Maps and Alipay). These third-party applications can be provided by content providers.
[0131] If the terminal device does not adopt the scheme of pre-installing applications for different user groups when performing OTA upgrade, the terminal device can display the interface shown in Figure 2B after the OTA upgrade.
[0132] Figure 2B shows the display interface of a terminal device after an OTA upgrade without using a user-specific pre-installed application scheme. This interface includes general applications and third-party applications (such as Memo, Huawei Innovation Research, Sports Health, Gaode Maps, and Alipay). These general and third-party applications can also be presented as service cards (such as Gaode public service cards and Alipay cards). Different users on different terminal devices will all have the same pre-installed applications added after the OTA upgrade. The first interface can be this display interface.
[0133] For example, user A's terminal device, user B's terminal device, and user C's terminal device all have the same applications installed after OTA upgrade (e.g., Memo, Huawei Innovation Research, Sports Health, Gaode Map, and Alipay).
[0134] If the terminal device already has one or more of the pre-installed applications installed before the OTA upgrade, the application will not be reinstalled.
[0135] For OTA upgrades that do not adopt a user-specific pre-installed application approach, if the applications installed on the terminal device do not meet the user's needs, it will negatively impact the user experience and leave a bad impression. For content providers, the low usage rate of the installed applications will affect the promotion of the pre-installed applications' business.
[0136] The terminal device can also be called the end-side device, user terminal, end-side, etc. The terminal device includes mobile devices (such as mobile phones, tablets, etc.) and Internet of Things (IoT) devices. This application does not limit the specific type of terminal device.
[0137] The terminal devices adopt a pre-installed application scheme based on different user groups. After OTA upgrade, the effects of the pre-installed applications for each user group can be displayed, as shown in Figures 2C to 2E.
[0138] Figures 2C to 2E illustrate three different pre-installed application effects. In Figure 2C, the terminal device belongs to user A; in Figure 2D, it belongs to user B; and in Figures 2E, it belongs to user C.
[0139] Among them, users A, B and C can each include different user tags, and the terminal device will pre-install applications according to different user tags during the OTA upgrade process.
[0140] User tags can be records that identify specific groups of people. For example, people living in city S can be recorded in the terminal device using the tag "City S"; people who frequently use application A can be recorded in the terminal device using the tag "Frequent User of Application A", etc. The correspondence between pre-installed applications and user tags can be found in Table 1.
[0141] Table 1
[0142] For example, Table 1 shows the correspondence between pre-installed applications and audience tags. Here, the target audience can be audience tags, and the pre-installed application can be any installed application. Table 1 is merely for explaining embodiments of this application and should not be construed as limiting the scope of the application. The matching relationship between different pre-installed applications and audience tags can be determined according to the actual needs of the pre-installed applications.
[0143] Different user tags can correspond to different pre-installed applications.
[0144] For example, for users whose profile is tagged as "having turned on their devices in the last two years and not having opened Alipay in the last 30 days", the pre-installed app that can be installed is "Alipay".
[0145] For example, for people whose demographic tags are "had their devices turned on in the last two years and whose city is Beijing", the pre-installed app that can be installed is "Eleme".
[0146] For example, for users whose tags are "their devices have been turned on in the last two years and they have not opened Gaode Maps in the last 30 days", the pre-installed application that can be installed is "Gaode Maps".
[0147] Different users can have different user tags. For example, users A, B, and C have different user tags. The user tags for different users can be found in Table 2.
[0148] Table 2
[0149] For example, Table 2 shows the user group tags for different users. Table 2 is only used to explain the embodiments of this application and should not be construed as limiting. The specific user group tags can be determined based on the specific tag content.
[0150] Different users can be associated with different user tags.
[0151] For example, User A's demographic tags are "activated in August 2022, city: Shanghai, frequent Alipay user, does not use Gaode Maps".
[0152] For example, user B's demographic profile is "purchased in March 2023, city: Guangzhou, uses Gaode Maps for navigation daily, and has not opened Alipay in the past month."
[0153] For example, user C's demographic tags are "started using the device in December 2021, city: Hangzhou, frequent Alipay user, uses Gaode Maps navigation daily".
[0154] Different terminal devices can install the same pre-installed applications during OTA (Over-The-Air) updates.
[0155] Figures 2C to 2E show the terminal devices of user A, user B, and user C. The terminal devices of user A, user B, and user C can all have the same pre-installed applications installed, which include general applications for the terminal devices.
[0156] For example, user A's terminal device, user B's terminal device, and user C's terminal device all have the same common application installed (such as Memo, Huawei Innovation Research, and Sports Health). This same application is installed uniformly when different users perform OTA upgrades, and it is not installed differently based on different user tags within the same installation batch.
[0157] Based on different user demographics, different pre-installed applications will be installed on different terminal devices during OTA upgrades.
[0158] Figure 2C shows that after User A's terminal device undergoes an OTA upgrade, the terminal device displays an interface with both general applications and pre-installed applications for specific user groups (such as Amap). The pre-installed applications for specific user groups are based on User A's user group tags.
[0159] For example, if user A's demographic tag indicates that user A does not use Amap, and meets the pre-installation conditions of Amap in the pre-installed applications (i.e., user A belongs to the target group of users who pre-install Amap), then user A's terminal device will undergo OTA upgrade to install Amap.
[0160] Figure 2D shows that after User B's terminal device undergoes an OTA upgrade, the device displays an interface with both general applications and pre-installed applications for specific user groups (such as Alipay). The pre-installed applications for specific user groups are based on User B's user group tags.
[0161] For example, if user B's demographic tag indicates that user B has not opened Alipay for a month, which meets the pre-installation conditions for Alipay in pre-installed applications (i.e., user B belongs to the target group for pre-installing Alipay), then user B's terminal device will have Alipay installed.
[0162] Figure 2E shows the interface of user C's terminal device after an OTA upgrade, displaying the pre-installed general applications. However, user C's user demographics did not match the target user group in the pre-installed applications, indicating that user C's terminal device only has general applications installed.
[0163] The terminal devices of users A, B, and C can be of the same model, for example, the terminal devices of users A, B, and C are mobile phones of the same model.
[0164] The terminal devices of users A, B, and C can also be different models of terminal devices. For example, the terminal devices of users A, B, and C can be mobile phones of different models.
[0165] Different users' terminal devices have general applications installed and applications pre-installed for specific user groups. Among them, the number of general applications is greater than the number of applications pre-installed for specific user groups.
[0166] Terminal devices can support various applications, such as Android apps and HarmonyOS atomic services. The pre-installed application solution for different user groups provided in this application embodiment can add different pre-installed applications to terminal devices after OTA upgrades, based on user profiles and content provider needs. These pre-installed applications can also be service cards.
[0167] As shown in Figure 3A, Figure 3A illustrates the system architecture for pre-installing applications for different user groups.
[0168] This method of pre-installing applications based on user demographics includes terminal devices, a Terminal Release Center (TRC) platform, an OTA server, a pre-installed service platform, and a user profiling platform. The terminal devices are the devices operated by the users.
[0169] When a terminal device detects a user's OTA (Over-The-Air) upgrade operation, the OTA upgrade component in the terminal device obtains the OTA upgrade package from the OTA server and receives the OTA upgrade package returned by the OTA server through the system update component at the application layer. The terminal device analyzes whether the OTA upgrade package needs to be pre-installed with applications for specific user groups. The first upgrade package can be this OTA upgrade package.
[0170] If the terminal device analyzes that the OTA upgrade package requires pre-installation of applications for different user groups, the terminal device obtains the list of pre-installed applications from the pre-installation service platform on the cloud side, and installs the pre-installed applications corresponding to the list through the Package Manager Service (PMS) in the application framework layer of the terminal device; if the terminal device analyzes that the OTA upgrade package does not require pre-installation of applications for different user groups, the terminal device can install all pre-installed applications through the PMS.
[0171] The cloud side, also known as cloud-side devices or the cloud itself, can include OTA servers, pre-installed service platforms, user profile platforms, and TRC platforms. OTA servers are used for remote component upgrades of terminal devices; pre-installed service platforms are used to configure the mapping relationship between the pre-installed application list and user tags; TRC platforms are used to configure whether to enable the pre-installed application list; and user profile platforms are used to configure user tags.
[0172] The terminal device includes an OTA (Over-The-Air) upgrade component. If the terminal device detects that a user has initiated an OTA upgrade, it uses this component to query the OTA upgrade package from the cloud-based OTA server. For example, if a user clicks on a device upgrade message that pops up on the terminal device, the terminal device can query the cloud-based OTA server for the OTA upgrade package.
[0173] During the OTA upgrade process, the system update component in the application layer of the terminal device can receive the OTA upgrade package returned from the OTA server. This OTA upgrade package includes a pre-installed configuration file for each user group (distinguish_crowd_profile.xml) and the installation packages for all pre-installed applications.
[0174] The installation packages for all pre-installed applications can be compressed and packaged in an OTA upgrade package, and then decompressed by the restoreAPK module in the application layer of the terminal device to obtain the installation packages for all pre-installed applications.
[0175] The user-specific pre-installation configuration file indicates whether pre-installed applications should be pre-installed according to user groups. In this configuration file, if the flag field (enable_configure) is enabled (e.g., enable_configure = 1), the terminal device uses user-specific pre-installed applications. If the flag field is disabled (e.g., enable_configure = 0), the terminal device installs all pre-installed applications.
[0176] When terminal devices adopt user-specific pre-installed applications, they can send a unique device identifier (UDID) and the version number of the OTA upgrade package to the cloud-based pre-installation service platform, and receive a list of pre-installed applications from the platform. The terminal device then installs the corresponding pre-installed application based on this list. Specifically, the terminal device can store the installation package of the pre-installed application in the application framework layer, and read and install the corresponding pre-installed application through the PMS (Application Management System). The unique device identifier (UDID) serves as the first user identifier.
[0177] The pre-installed application list received by the terminal device can be in the form of a whitelist, meaning the terminal device installs pre-installed applications that are on the whitelist. Alternatively, the terminal device can receive the pre-installed application list in the form of a blacklist, meaning the terminal device installs pre-installed applications that are not on the whitelist. This application embodiment does not limit the specific form of the pre-installed application list.
[0178] The terminal device can send its UDID to the pre-installed service platform to obtain the list of pre-installed applications. Alternatively, the terminal device can send its UDID and OTA upgrade package version number to the pre-installed service platform. The OTA upgrade package version number can be used to obtain the list of pre-installed applications corresponding to the OTA upgrade version. This application embodiment does not limit the specific information sent by the terminal device to the pre-installed service platform. The OTA upgrade package version number is a first version, and the first message may include the UDID and the OTA upgrade package version number.
[0179] The pre-installed service platform is used to configure the mapping relationship between pre-installed applications and user tags, and also to generate and distribute a list of pre-installed applications. The pre-installed service platform obtains user tags from the user profile platform, enabling synchronization between the user tags on the pre-installed service platform and those on the user profile platform.
[0180] The pre-installation business platform accepts configuration operations from pre-installation operators to configure pre-installation strategies for specific models or batches of pre-installation packages. For example, for pre-installation packages in the Mate60 and R1 batches, the pre-installation strategy for application A (such as JD.com) is to install the application on all devices that receive the pre-installation package (i.e., full installation), the pre-installation strategy for application B (such as Toutiao) is full installation, and the installation strategy for application C (such as Alipay) is to install the application on devices with specific user tags (such as user tag 1, user tag 3) (i.e., segmented pre-installation).
[0181] The pre-installed service platform generates and saves a list of pre-installed applications for each of the configured pre-installed strategies.
[0182] The pre-installed service platform receives the UDID and pre-installed package version number of the terminal device, determines the corresponding list of pre-installed applications, and returns the list of pre-installed applications to the terminal device.
[0183] The pre-installed service platform can add tag fields to the pre-installed package. The pre-installed service platform can also send the generated pre-installed package to the OTA server.
[0184] The pre-installed service platform can also add different flag fields to different pre-installed packages. When a pre-installed package is sent to the TRC platform, the TRC platform sets the values of these flag fields in different pre-installed packages to control which terminal devices request the pre-installed application list from the pre-installed platform and which terminal devices directly install all pre-installed applications in the OTA package without requesting the pre-installed application list from the pre-installed platform. This alleviates the traffic pressure on the pre-installed platform. Specifically, the flag field can be set to an enabled value (e.g., enable_configure = 1), which instructs the terminal device to obtain the pre-installed application list from the pre-installed service platform; the flag field can be set to a disabled value (e.g., enable_configure = 0), which instructs the terminal device to directly install all pre-installed applications in the OTA package without requesting the pre-installed application list from the pre-installed service platform.
[0185] The user profiling platform is used to create user tags and match suitable devices based on these tags. The platform can query user tags matched to terminal devices using their UDIDs and determine the suitability of a user tag by the number of matched devices.
[0186] The TRC platform supports software version management for all products, including mobile phones, tablets, and personal computers. It is also used to release software update information to production lines, service providers, Huawei AppGallery, and consumers, as well as to provide functions such as third-party software management, product catalog management, and data service provisioning.
[0187] A user profile platform can include the identifier of a terminal device (such as UDID) and the user's operational information for that device (such as the device's location, the user's age, and the user's actions on applications). This user operational information is information that the user has authorized the cloud (such as the user profile platform) to access. The user profile platform can obtain demographic tags (or user profiles) from this user operational information. For example, if the location of the first device is the first city (such as Beijing), the user's age is the first age group (such as 45 years old), and the application frequently used by the user is the third application (such as legal consulting software), the user profile platform can determine the first tag for the first device (such as "Beijing; over 40 years old; legal profession").
[0188] The user profile platform can also create user tags. The platform obtains the number of terminal devices corresponding to each user tag. If the number of terminal devices exceeds a threshold (e.g., 100,000), the platform can activate the user tag. Otherwise, it can deactivate the tag. The platform can then send the activated user tags to pre-installed application platforms.
[0189] In some implementations, the pre-installed service platform and the portrait platform may belong to the same server. Specifically, the pre-installed service platform can be a pre-installed service module within the server, performing operations similar to those of the pre-installed service platform; the portrait platform can be a portrait platform module within the server, performing operations similar to those of the portrait platform. Communication between the pre-installed service platform and the portrait platform can be internal communication between the pre-installed service module and the portrait platform module within the same server. This application does not restrict whether the pre-installed service platform and the portrait platform belong to the same server.
[0190] The TRC platform can be used to release OTA upgrade packages and mark whether the OTA upgrade package needs to be pre-installed with applications for different user groups.
[0191] The TRC platform can be used to receive and save preload packages released by pre-installed business platforms. These preload packages include version numbers and compressed files containing all pre-installed applications.
[0192] The TRC platform can accept configuration administrator operations to publish package bundles to the OTA server. These bundle bundles can also be generated by the TRC platform by combining pre-installed packages with pre-installed files tailored to different user groups, thus forming OTA upgrade packages.
[0193] The TRC platform can set flag fields in different pre-installed packages to control which devices request the pre-installed application list from the pre-installed service platform, and which devices directly install all pre-installed applications in the OTA package without requesting the pre-installed application list from the pre-installed platform, thereby alleviating the traffic pressure on the pre-installed service platform. For example, when the TRC platform detects that the traffic of the pre-installed service platform exceeds a threshold (such as the maximum traffic value of the pre-installed service platform), it can control the flag fields of some terminal devices (such as half of the total number of terminal devices) to be turned off, reducing the access traffic to the pre-installed service platform. This portion of the OTA package can be half of the total OTA packages, or it can be any number of OTA packages; this embodiment does not limit this.
[0194] In some implementations, the pre-installed service platform and the TRC platform belong to the same server. The pre-installed service platform can be a pre-installed service module within the server, performing operations similar to those of the pre-installed service platform. The TRC platform can be a TRC platform module within the server, performing operations similar to those of the TRC platform. Communication between the pre-installed service platform and the TRC platform can be internal communication between the pre-installed service module and the TRC platform module within the same server. This application does not restrict whether the pre-installed service platform and the TRC platform belong to the same server.
[0195] The OTA server can receive the combined package from the TRC platform and combine it with the necessary information for OTA upgrades (such as system update information) to generate an OTA upgrade package.
[0196] OTA servers are used to send OTA upgrade packages to terminal devices.
[0197] The OTA server can receive OTA upgrade information from terminal devices and search for the target OTA upgrade package within the OTA server. Once the target OTA upgrade package is found, it is sent to the terminal device. This OTA upgrade package contains pre-installation files for specific user groups, which indicate whether pre-installation is required for that group.
[0198] The solution and related apparatus for pre-installing applications for different user groups provided in this application can solve the problems of not supporting segmented operation during OTA upgrades, long OTA upgrade times, and applications installed on terminal devices not closely matching user needs. Specifically, it includes: the terminal device sending its UDID to the cloud, the cloud returning a list of pre-installed applications for the terminal device, and the terminal device installing different pre-installed applications through this list. The pre-installed application list is generated in the cloud, supporting segmented pre-installation and segmented operation; the OTA upgrade package includes the installation packages for the pre-installed applications, eliminating the need for the terminal device to download separate application installation packages, thus shortening OTA upgrade time; the pre-installed service platform uses user tags provided by a user profile platform to solve the problem of matching pre-installed applications with user needs.
[0199] In some implementations, the TRC platform can set flag fields in different pre-installed packages to prevent surge traffic from affecting the pre-installed service platform. Surge traffic refers to network traffic exceeding normal network traffic or the network traffic limits of the cloud platform for a short period of time. Surge traffic can cause equipment failure on the cloud platform.
[0200] This application provides an implementation method for pre-installing applications for different user groups on the system side.
[0201] As shown in Figure 3B, the system-side method for pre-installing applications for different user groups provided in this embodiment may include the following specific steps:
[0202] S11. The electronic device obtains a first upgrade package, which includes installation packages for N applications.
[0203] The first upgrade package can be an OTA upgrade package. OTA upgrades can be performed when the terminal device is running normally. For example, the electronic device can receive user input and send information to the OTA server to obtain the OTA upgrade package. The electronic device can also be set to automatically obtain the OTA upgrade package, sending a request to the OTA server to obtain the OTA upgrade package when a new version of the first operating system is detected. In this embodiment, the terminal device includes an electronic device, which can be a mobile phone.
[0204] Terminal devices can download OTA upgrade packages after receiving user input (such as clicking the OTA upgrade button), or they can download them automatically without affecting user experience (for example, electronic devices can automatically download OTA upgrade packages when connected to a wireless LAN WLAN). Different terminal devices can download the same batch of OTA upgrade packages, and each batch of OTA upgrade packages includes installation packages for N applications.
[0205] Terminal devices can detect identifiers in OTA update packages. When a terminal device detects that an identifier is enabled, it needs to obtain the corresponding application list. For example, an electronic device can detect an identifier in an OTA update package, and upon determining that the identifier is enabled, the electronic device determines that it needs to obtain the application list. In this embodiment, the identifier can be referred to as a flag field (such as enable_configure).
[0206] The terminal device obtains the OTA upgrade package and determines the list of applications that need to be obtained.
[0207] The terminal device sends a request to the server to obtain an application list. This request includes the terminal device's UDID. The server stores a mapping between user tags and applications. Upon receiving the terminal device's UDID, the server retrieves the user tag corresponding to that UDID and generates a first application list based on the mapping between user tags and applications. User tags are markers indicating specific user groups. For example, users residing in city S can be recorded in the electronic device using the tag "city S"; users who frequently use application A can be recorded in the electronic device using the tag "frequent user of application A," etc. These recorded tags can be user tags. In this embodiment, the server can be a pre-installed service platform, and the first application list can also be referred to as a first pre-installed application list.
[0208] For example, an electronic device sends a UDID to a server, and the server obtains the tag of the first group corresponding to that UDID. In this embodiment of the application, the tag of the group can be called a group tag, and the tag of the first group can be called a first tag.
[0209] The first group's tags can include one or more original tags, such as the location of the terminal device, the time the terminal device is powered on, and the frequency of application usage on the terminal device. Different original tags can be arbitrarily arranged and combined to form the tags for the first group. For example, if the original tags are "Shanghai", "powered on within 2 years", "high-frequency use of application A", and "no use of application D", the tags for the electronic device group can be "city Shanghai, powered on within 2 years, high-frequency use of application A, no use of application D".
[0210] In some implementations, the server can send the UDID of the terminal device and the tag of the crowd to the profiling platform. The profiling platform uses the UDID to determine the tag of the first crowd from the received tags of the crowd and sends the tag of the first crowd to the server. The server and the profiling platform can belong to the same server or different servers. When the server and the profiling platform are the same server, the tasks performed by the server can be regarded as the tasks performed by the first module, and the tasks performed by the profiling platform can be regarded as the tasks performed by the profiling module. The communication between the server and the profiling platform can be understood as the communication between the first module and the profiling module. In the embodiments of this application, the profiling platform has the tags of the crowd and can also be referred to as the first server.
[0211] The server can identify the application on a terminal device based on the tags of a first-level user group and generate a list of applications corresponding to that application. Each application can have corresponding user tags. The server compares the user tags of the electronic device with the user tags of the application. If the user tags of the electronic device include the user tags of the application, then the application is identified as an application on the terminal device. For example, if the user tags for application "Application D" are "Powered on within the last two years and not opened in the last 30 days," and the user tags for the electronic device include "Powered on within the last two years, but not using Application D," then the electronic device includes "Application D." The server generates a first list of applications including the name "Application D."
[0212] The first application list can be in blacklist form. This blacklist format adds the application name to the application list if it is not an application for the terminal device. For example, if the tag for users of application "Application D" is "users who have powered on their devices within the last two years and have not opened application D in the last 30 days," and the tag for users of electronic devices includes "users who have powered on their devices within the last two years and have frequently used application D in the last 30 days," then application "Application D" is not included in the application list for electronic devices. The server generates a first application list that includes the name "Application D."
[0213] The terminal device sends a request to the server to obtain a list of applications. This request may also include batches of OTA upgrade packages downloaded by the terminal device. After receiving the batch of OTA upgrade packages, the server identifies tags for multiple user groups within the corresponding batch of OTA upgrade packages. This application embodiment does not limit the specific content of the information sent by the terminal device to the server.
[0214] S12. The electronic device sends a first message to the server, which is used by the server to determine N and M applications in the application, where M is less than or equal to N and M and N are positive integers.
[0215] The server can determine, through a first message, the M applications that need to be installed out of the N applications in the OTA upgrade package of the electronic device. In this embodiment, the first message includes a first user identifier and a first version. The first user identifier is a UDID, and the first version is the version number of the OTA upgrade package. Specifically, the server can obtain a user group tag through the UDID, and then use this tag to confirm the M applications that need to be installed. The server stores the correspondence between UDIDs and user group tags, and also stores the relationship between the user group tag and the applications that need to be installed on the electronic device. Thus, the server can obtain the user group tag based on the UDID, and then obtain the M applications to be installed on the electronic device based on the user group tag. The server can confirm that the electronic device has downloaded the installation packages for the N applications through the version number of the OTA upgrade package.
[0216] S13. The electronic device receives a first application list returned by the server, the first application list including the M applications.
[0217] The server returns a list of applications to the terminal device, which then receives the list. For example, the server returns a first list of applications to an electronic device, which receives this first list containing M applications (e.g., the names of the M applications).
[0218] S14. If the first application list is a whitelist, the electronic device installs the M applications according to the first application list; if the first application list is a blacklist, the electronic device installs the NM applications according to the first application list.
[0219] When the first application list is in whitelist form, the electronic device obtains N applications from the OTA package and installs M applications indicated by the first application list.
[0220] These M applications can be tailored to users of electronic devices. For example, if the tags for users of electronic devices show that they frequently use navigation application E, then the M applications could include navigation application F, etc. Users can use navigation application F to navigate and meet their travel and wayfinding needs.
[0221] These M applications can also be applications promoted to potential users. For example, if an electronic device user frequently uses payment application G but has never used payment application H, then payment application H can be included among the M applications. Users can use payment application H to make payments, thus promoting payment application H.
[0222] When the first application list is in the form of a blacklist, after the electronic device detects records of M applications in the first application list, it installs NM applications from the N applications, excluding the M applications.
[0223] Applications in an electronic device can be displayed as application icons or as service cards. This application does not limit the specific form of pre-installed applications.
[0224] This application also relates to two embodiments: Embodiment 1 and Embodiment 2.
[0225] Example 1 illustrates how this application's embodiment connects the profiling platform, pre-installed service platform, OTA server, and terminal device to complete the process of pre-installing applications for different user groups. This embodiment mainly achieves the following three objectives:
[0226] 1. During the OTA upgrade phase, the goal is to enable terminal devices targeting different user groups to obtain pre-installed applications that meet user needs;
[0227] 2. Multiple terminal devices and the cloud platform are associated with each other to ensure that a terminal device can obtain a unique list of pre-installed applications in real time during OTA upgrades;
[0228] 3. The pre-installation strategy for terminal devices can be dynamically adjusted to achieve a complete closed loop of business capabilities for pre-installing applications for different user groups.
[0229] Based on the scheme in Embodiment 1, Embodiment 2 introduces the addition of control capabilities to the TRC platform and the use of a pre-installed application list in the form of a blacklist, thereby achieving the robustness of the cloud-side system in the scenario of traffic surges in this application embodiment.
[0230] Example 1
[0231] This embodiment includes a management-side process and a user-side process. The management-side process, from the perspective of pre-installation operations personnel, describes how to establish a mapping relationship between user tags and pre-installed applications. The user-side process, from the perspective of terminal device users, describes how to obtain pre-installed applications that meet user needs during OTA upgrades. The purpose of the management-side process is to configure the mapping relationship between the pre-installed application list and user tags, and it is a prerequisite for the implementation of the user-side process.
[0232] In the management process, pre-installation operations personnel create user tags on the profiling platform based on the content provider's (CP) requirements. The profiling platform then calculates matching terminal device users based on these user tags. The UDID of the terminal device has a one-to-one correspondence with the field used to identify the device within the profiling platform.
[0233] During the user-side process, when a terminal device performs an OTA upgrade, it can obtain pre-installed applications that meet the user's needs.
[0234] As shown in Figure 4, Figure 4 illustrates the method and flow for creating crowd tags on the cloud side.
[0235] S101. Pre-installed operations personnel create audience tags on the profile platform.
[0236] Pre-installed operations personnel enter the profiling platform and create multiple user tags, see Table 3.
[0237] Table 3
[0238] Table 3 shows the detailed information of the population tag list, including the serial number, population tag ID, population tag name, and population tag. For example, the population tag "Beijing; 40 years and older; Law;" corresponds to the population tag name "Beijing Legal Industry Population" and the corresponding population tag ID "1348204237253176". Another example is the population tag "Shanghai; 65 years and older; Health and Wellness;" which corresponds to the population tag name "Shanghai Retirees" and the corresponding population tag ID "1348204096784952". Table 3 is only used to explain the embodiments of this application and should not be construed as limiting. The specific content of the population tag ID, population tag name, and population tag can be determined according to actual application needs.
[0239] Among them, the serial number and the audience tag ID are used to mark different audience tags, the audience tag name is used to describe the audience tag in words, and the audience tag records the identity characteristics of different users or the common identity characteristics of different user groups.
[0240] This user group can be distinguished from multiple dimensions, including but not limited to: region, user age, user occupation, family status, application activity, hobbies, etc. Different dimensions of tags can be logically combined to form a user group tag that includes one or more different dimensions of tags.
[0241] For example, the geographic dimension of the audience tag includes regions such as Beijing, Shanghai, Hangzhou, and Nanjing; the age dimension of the audience tag includes age ranges such as under 18, 18-25, 25-35, 35-40, and over 40; and the occupation dimension of the audience tag includes professions such as finance, accounting, and law.
[0242] Different dimensions of audience tags can be combined to form a specific audience tag. For example, audience tag number 1 could be Beijing; over 40 years old; law; or audience tag number 3 could be Hangzhou; accounting major; 18-25 years old. Different audience tags can have different tags of the same dimension.
[0243] S102. The profile platform calculates a unique device identifier that matches the population tag.
[0244] The user profile platform can obtain the corresponding UDIDs from multiple user tags. For example, if the user profile platform sets the user tag to the second city (such as "Shanghai"), it can add the UDIDs that include the second city to the device identifier corresponding to that user tag. For example, if the user tags for the fourth and fifth UDIDs are the second city, and the user tag for the sixth UDID is the third city, then the UDIDs corresponding to the user tags set by the user profile platform will include the fourth and fifth UDIDs.
[0245] S103. The profile platform is activated and the population is updated regularly.
[0246] The user profile platform activates user tags and regularly updates the stored user group records.
[0247] The user profile platform can calculate the user groups corresponding to the user tags, which can be used to verify the rationality of the tag creation.
[0248] For example, the pre-installed operations staff might configure the following user tags: Xi'an; Internet; 20-25 years old. If the user profile platform matches a small number of UDIDs that match these tags, the pre-installed operations staff can conclude that the user group corresponding to these tags is too small, the tag is unreasonable, and thus disable the tag.
[0249] For example, pre-installed operations personnel might configure user tags as: Hangzhou; Internet; 20-25 years old. If the user profile platform matches a large number of UDIDs that match these tags, the pre-installed operations personnel can assume that the user group corresponding to these tags is large and that the tags are valid, and thus activate these tags.
[0250] Among them, the profiling platform can determine whether the number exceeds a threshold (such as 100,000) and confirm the number of terminal devices that meet the population tags.
[0251] For example, if the profiling platform determines that the number of terminal devices that meet the population tags is less than or equal to the threshold, it considers the number to be small; if the profiling platform determines that the number of terminal devices that meet the population tags is greater than the threshold, it considers the number to be large.
[0252] The user profile platform can also accept pre-installed operations from operations personnel, allowing them to use user tags during specific time periods (e.g., during an application A campaign). The platform can also remove user tags that have been set for a long period (e.g., exceeding a set duration).
[0253] After creating audience tags, pre-installation operations personnel need to configure the mapping relationship between the pre-installed application list and the audience tags. The pre-installed application list can be represented as a list of applications that need to be pre-installed.
[0254] As shown in Figure 5, Figure 5 illustrates the method and flow of configuring the list of pre-installed applications and mapping user tags on the cloud side.
[0255] S201. Pre-installation operations personnel create pre-installation strategies for different user groups on the pre-installation business platform.
[0256] The pre-installation service platform receives the operation from the pre-installation operations personnel and displays the management interface for pre-installation strategies based on different user groups. The pre-installation operations personnel can configure different pre-installation strategies in this management interface, as shown in Figure 6.
[0257] Figure 6 shows the management interface for pre-installation strategies for different user groups, accessed by pre-installation operations personnel. The configuration of pre-installation strategies for different user groups includes strategy name, external model, batch, pre-installation package version number, generation status, creation time, creator, and pre-installation strategies for operations and applications (not shown).
[0258] Among them, the strategy name is the name set by the pre-installed operator; the external model is the terminal device model to which the pre-installed strategy applies; the batch can be the name indicating different pre-installed strategies; the pre-installed package version number is the name of the pre-installed package carrying the pre-installed strategy; and the generation status displays the current status of the pre-installed strategy. For the generation status of pre-installed strategies for different groups of people, if the strategy is configured successfully, the generation success status can be displayed; if the strategy fails to be configured, the generation failure status can be displayed.
[0259] Pre-installation operations personnel can edit or delete records of each pre-installation strategy for different user groups.
[0260] Pre-installation operations personnel can query, add, or reset records of pre-installation strategies for different user groups based on information such as time, strategy name, batch, and pre-installation package version number.
[0261] S202. The pre-installed business platform obtains user tags from the user profile platform.
[0262] The pre-installed service platform sends a request to the user profile platform to obtain the activated user tags from the user profile platform. The user tags can be found in Table 3 above, and will not be repeated here.
[0263] In some implementations, the pre-installed service platform and the portrait platform belong to the same server. The pre-installed service platform can be a pre-installed service module on the server, which performs operations similar to those of the pre-installed service platform. The portrait platform can be a portrait platform module on the same server, which performs operations similar to those of the portrait platform. Communication between the pre-installed service platform and the portrait platform can be internal communication between the pre-installed service module and the portrait platform module on the same server. This application does not limit whether the pre-installed service platform and the portrait platform belong to the same server.
[0264] S203. Pre-installed business platform analyzes the list of pre-installed applications.
[0265] Pre-installation operations personnel can select a specific version of the pre-installation package on the pre-installation business platform and view the list of pre-installed applications in that package.
[0266] For example, the pre-installed package for the first version may include N pre-installed applications. Here, N is a positive integer greater than zero, and the pre-installed applications can be online shopping applications (such as "Pinduoduo"), platform applications (such as "Douyin"), financial applications (such as "Wind"), etc. The term "pre-installed application" refers to any application that can be pre-installed.
[0267] S204. Pre-install business platform configuration of user tags and pre-installed application mapping.
[0268] Pre-installation operations personnel can configure pre-installed application installation strategies, which may include whether the pre-installed application adopts a segmented pre-installation approach, the user tags configured for the pre-installed application, etc., as shown in Figure 7.
[0269] Figure 7 shows the interface for pre-installation operations personnel to add pre-installation strategies for different user groups. Pre-installation operations personnel can set the strategy name, external model, batch, pre-installation package version number, and pre-installation strategies for different applications to generate pre-installation strategies for different user groups. The configuration strategies for different applications can be different.
[0270] For example, online shopping apps (such as "Pinduoduo") and platform apps (such as "Douyin") can be configured to install on all devices that download the pre-installation package (i.e., full pre-installation). Financial apps (such as "Wind") can be configured for segmented pre-installation. Specifically, when pre-installation operators select segmented pre-installation, they can click a dropdown menu in the corresponding audience tag selection field. This dropdown menu will contain the activated audience tag data queried in step S202. Based on these audience tags obtained from the pre-installation business platform, pre-installation operators can determine the appropriate audience tags for the terminal devices where the financial app can be installed.
[0271] S205. The pre-installation business platform returns the pre-installation strategy results for different user groups to the pre-installation operations personnel.
[0272] Pre-installation operations personnel can determine whether to reconfigure the pre-installation strategy for the target audience based on the returned pre-installation strategy configuration results.
[0273] For example, if the pre-installation service platform shows that adding pre-installation configurations failed, the pre-installation operations personnel need to reset the pre-installation strategy for different user groups.
[0274] As shown in Figure 8A, Figure 8A illustrates the process by which a terminal device obtains pre-installed applications that meet user needs during an OTA upgrade. The specific process is as follows:
[0275] S301. The terminal device receives a user click and performs an OTA upgrade.
[0276] Once the terminal device receives the user's click action and detects an OTA upgrade package with the latest software and hardware settings, it begins the OTA upgrade process.
[0277] In some implementations, the terminal device can be configured to automatically download OTA upgrade packages, meaning the terminal device automatically detects the latest version of its hardware and software. Upon confirming the existence of the latest version of the terminal device's hardware and software, and if the terminal device is connected to a wireless local area network (WLAN), the corresponding OTA upgrade package is automatically downloaded in the background. After receiving an upgrade request from the user, the terminal device can directly execute step S303 and subsequent steps.
[0278] S302. The terminal device sends a request to the OTA server to search for OTA upgrade packages, and the OTA server returns the search results.
[0279] The terminal device sends a request to the OTA server to obtain the OTA upgrade package. The OTA server can search and return the latest OTA upgrade package corresponding to the terminal device. This upgrade package includes: a pre-installed configuration file for a specific user group (distinguish_crowd_profile.xml) and installation packages for all pre-installed applications.
[0280] Among these, all pre-installed applications can be pre-installed applications set up in the pre-installed business platform. For example, online shopping applications (such as "Pinduoduo"), platform applications (such as "Douyin"), financial applications (such as "Wind"), navigation applications (such as "Gaode Map"), payment applications (such as "Alipay"), and general applications (such as "Memo").
[0281] The pre-installed application can also be associated with the version number of the OTA upgrade package. For example, the first version of the OTA upgrade package may include online shopping applications, platform applications, navigation applications, and general applications, while the second version of the OTA upgrade package may include financial applications, navigation applications, payment applications, and general applications.
[0282] The installation package of the pre-installed application can be compressed and carried in the OTA upgrade package. The terminal device can allocate a specified storage size for the data space (such as ROM) storing the OTA upgrade package.
[0283] In some implementations, when a terminal device downloads an OTA upgrade package multiple times, it can also delete the previously downloaded OTA upgrade package, thus avoiding the occupation of the terminal device's storage space after multiple OTA upgrades.
[0284] S303. Terminal device parses configuration file.
[0285] The terminal device parses the OTA upgrade package sent by the OTA server and detects the pre-installed configuration files for different user groups within the OTA upgrade package. The terminal device checks a flag field (e.g., enable_configure). If the flag field is the first value (i.e., an enabled value, e.g., 1; if the flag field is the first value, e.g., enable_configure=1), it indicates that the terminal device's pre-installed user group capability is enabled. In this case, the terminal device, the pre-installed service platform, and the user profile platform together execute subsequent steps S304-S306. If the flag field is the second value (i.e., a disabled value, e.g., 0; if the flag field is the second value, e.g., enable_configure=0), it indicates that the terminal device's pre-installed user group capability is disabled. In this case, the terminal device directly executes subsequent step S307. The flag field is the first identifier.
[0286] S304. The terminal device requests the list of pre-installed applications from the pre-installed service platform based on the UDID and the pre-installed package version number.
[0287] The terminal device sends its UDID and the version number of the downloaded pre-installed package to the pre-installed service platform, which then queries the platform for the corresponding list of pre-installed applications. The pre-installed service platform stores a mapping between user tags and pre-installed applications. It can retrieve the corresponding user tags using the UDID and generate a first application list based on this mapping.
[0288] S305. The pre-installed business platform obtains user tags from the user profile platform based on the UDID and pre-installed package version number.
[0289] The pre-installed service platform provides the terminal device's UDID and the pre-installed user tag list to the profiling platform to determine which user tags the current user meets, as shown in Figure 8B.
[0290] Figure 8B illustrates the specific information exchanged between the pre-installed service platform and the profiling platform. The pre-installed service platform sends request parameters to the profiling platform, which include the UDID of the terminal device and the population tags set by the pre-installed service platform. For example, the UDID sent by the pre-installed service platform is device001, and the population tags set by the pre-installed service platform include A, B, C, and D.
[0291] The user profile platform receives a UDID and multiple user tags from the pre-installed service platform, and then identifies the user tags that match the UDID. For example, the user profile platform sequentially obtains the UDIDs corresponding to user tags A, B, C, and D, compares them with device001, and determines that the user tags including device001 are A and D.
[0292] The user profile platform sends matching audience tags to the pre-installed service platform. For example, audience tags A and D indicate that the audience tags corresponding to device001 are A and D.
[0293] In some implementations, the pre-installed business platform and the portrait platform belong to the same server. For details, please refer to step S202 in Figure 5 above, which will not be repeated here.
[0294] S306. The pre-installed business platform reads the list of pre-installed applications corresponding to the user tags.
[0295] The pre-installed service platform obtains a list of pre-installed applications corresponding to user tags and returns this list to the terminal device. The pre-installed application list is a list of pre-installed applications.
[0296] For example, the pre-installation service platform obtains all pre-installed applications set in the pre-installation package. When pre-installing applications by segmented user groups, it compares the corresponding user group tags with the received user group tags to determine the pre-installed application list for the terminal device. For instance, the user group tags obtained by the pre-installation service platform are A and D. The pre-installed applications set by the platform can include navigation applications, payment applications, and general applications. The navigation application, whose segmented user group tag is A, belongs to the user group tags obtained by the pre-installation service platform; the payment application, whose segmented user group tag is B, does not belong to the user group tags obtained by the pre-installation service platform; and the general applications are pre-installed in all categories. The terminal device can then determine its own pre-installed application list from this list, which can include both navigation applications and general applications.
[0297] The pre-installed service platform returns a list of pre-installed applications to the terminal device, and the terminal device installs the pre-installed applications indicated in the list.
[0298] S307. The terminal device PMS reads and installs the policy.
[0299] The terminal device obtains the downloaded pre-installed application installation package, identifies the pre-installed application installation package that matches the pre-installed application list (e.g., decompressing the application indicated in the pre-installed application list to the application framework layer), and installs the selected pre-installed application through PMS. For example, the pre-installed application list includes navigation applications (such as "Gaode Maps") and general applications (such as "Notes"). The terminal device can install the navigation application and the general application from the pre-installed applications.
[0300] The list of pre-installed applications can also be in the form of a blacklist. That is, if the list of pre-installed applications includes a payment application (such as "Alipay"), then the terminal device will install other pre-installed applications besides the payment application.
[0301] In some implementations, if the terminal device detects that the flag field is the second value (e.g., enable_configure=0), it will obtain all pre-installed application installation packages downloaded (e.g., decompress all pre-installed application installation packages downloaded to the application framework layer) and install all pre-installed applications through PMS.
[0302] In some implementations, when there are no pre-installed configuration files for specific user groups in the pre-installed package, the PMS will load the installation packages for all pre-installed applications.
[0303] S308. The terminal device notifies the user that the upgrade is complete.
[0304] Once the OTA upgrade of the terminal device is complete, the updated pre-installed applications can be displayed on the terminal device. For example, if the pre-installed applications on the electronic device include navigation applications (such as "Gaode Maps"), the terminal device can display the navigation application's icon and / or application card after the update, as shown in Figure 2C, which will not be elaborated further here. As another example, if the pre-installed applications on the electronic device include payment applications (such as "Alipay"), the terminal device can display the payment application's icon and / or application card after the update, as shown in Figure 2D, which will not be elaborated further here.
[0305] Different terminal devices may display different interfaces or the same interface after an OTA upgrade. Specifically, if different terminal devices have different lists of pre-installed applications, they will display different interfaces after the OTA upgrade; if they have the same list of pre-installed applications, they will display the same interface. This application does not limit the interface displayed by different terminal devices after an OTA upgrade.
[0306] As shown in Figure 8A, the terminal device obtains a pre-installed application that meets the user's needs. The effect of this method is shown in Figures 2A-2E (taking the implementation effect on a mobile phone as an example; the embodiments of this application are applicable to all terminal devices).
[0307] As shown in Table 1, the correspondence between pre-installed applications and user tags is as follows. Applications listed in the table need to be pre-installed according to user groups. Pre-installation personnel will match the user tags corresponding to the tag numbers of the pre-installed applications on the pre-installation business platform. For example, mapping navigation application E (e.g., "Gaode Maps") to the user tag "users who have powered on their devices within the last two years and have not opened navigation application E in the last 30 days." Another example is mapping payment application H (e.g., "Alipay") to the user tag "users who have powered on their devices within the last two years and have not opened payment application H in the last 30 days."
[0308] As shown in Table 2, the user profile platform calculates that user A meets the feature of tag number 3, user B meets the feature of tag number 1, and user C does not meet any of the features of tag number 1 to 3.
[0309] As shown in Figure 2C, after the OTA upgrade, user A's terminal device added the navigation application E (i.e., "Gaode Maps").
[0310] As shown in Figure 2D, after the OTA upgrade, user B's terminal device displays the payment application H (i.e., "Alipay").
[0311] As shown in Figure 2E, since user C does not match any user demographic tags, the terminal device does not add any applications that require pre-installation based on user demographics after the OTA upgrade. For example, general applications (such as "Memo", "Huawei Innovation Research", and "Health") are applications that do not require pre-installation based on user demographics, and they are added to all three terminal devices after the OTA upgrade.
[0312] Compared with the prior art, the main improvements of the embodiments in this application include the following aspects:
[0313] Firstly, during the OTA upgrade phase, different pre-installed applications are installed on terminal devices corresponding to different user groups, thus achieving pre-installed applications for different user groups.
[0314] Secondly, the profiling platform calculates the user tags corresponding to the terminal devices, and then installs application software that matches the user tags on the terminal devices. The application software installed on the terminal devices is close to the consumers.
[0315] Thirdly, during the OTA upgrade phase, the terminal device only needs to read the pre-installed application installation package from the OTA package and query the cloud for the list of applications to be installed, which reduces the amount of data interaction between the terminal and the cloud and shortens the OTA upgrade time.
[0316] Example 2
[0317] As shown in Figure 9, Figure 9 illustrates the method and process for improving the robustness of cloud-side platforms to surge traffic.
[0318] In Example 1, the pre-installation personnel configured the mapping relationship between pre-installed applications and audience tags (refer to step S204 in Figure 5). To improve the robustness of the cloud platform under surge traffic, a blacklist of pre-installed applications is generated asynchronously after the mapping configuration is completed, and the TRC platform is configured to determine whether the pre-installed package supports audience-based pre-installation. The optimization steps are shown in steps S405-S407 in Figure 9. The specific implementation process is as follows:
[0319] S401. Pre-installation operations personnel create pre-installation strategies for different user groups on the pre-installation business platform.
[0320] For details, please refer to step S201 in Figure 5 above, which will not be repeated here.
[0321] S402. The pre-installed business platform obtains user tags from the user profile platform.
[0322] For details, please refer to step S202 in Figure 5 above, which will not be repeated here.
[0323] S403. Pre-installed business platform analyzes the list of pre-installed applications.
[0324] For details, please refer to step S203 in Figure 5 above, which will not be repeated here.
[0325] S404. Pre-installed business platform configuration of audience tags and pre-installed application mapping.
[0326] For details, please refer to step S204 in Figure 5 above, which will not be repeated here.
[0327] S405. Pre-installed business platform generates blacklist.
[0328] The pre-installed business platform generates and stores a blacklist based on the mapping relationship between user tags and pre-installed applications, as shown in Figure 10.
[0329] Figure 10 illustrates the cloud-based blacklist generation process. The cloud side includes a pre-installed service platform. This platform establishes a mapping between applications and user tags. For example, the pre-installed application for user tags A and B is application Name1, and the pre-installed application for user tag C is application Name2. User tags include user tags A, B, and C, and pre-installed applications include application Name1 and application Name2.
[0330] The pre-installed service platform generates a blacklist based on the user tags of terminal devices, using the mapping relationship between applications and user tags, resulting in a cloud-side blacklist. For example, a terminal device can have only one user tag: a terminal device with user tag A or user tag B has application Name2 in the pre-installed application blacklist; a terminal device with user tag C has application Name1. Alternatively, a terminal device can have multiple user tags: a terminal device with both user tags A and B has application Name2 in the pre-installed application blacklist; a terminal device with both user tags C and A, or both user tags C and B, has an empty blacklist, meaning both application Name1 and application Name2 are pre-installed applications. If a terminal device's user tag does not belong to the user tags in the application-user tag mapping relationship (e.g., the terminal device's user tag is user tag D), then the pre-installed application blacklist includes application Name1 and application Name2, meaning no application is a pre-installed application. The cloud-side blacklist can also include the installation package paths of the blacklisted applications. For example, for blacklisted applications (including application Name1 and application Name2) whose audience tags belong to "Others" (i.e., audience tags do not belong to audience tags A, B, and C), the location of each blacklisted application in the OTA upgrade package is given (e.g., the path of application Name1 in the OTA upgrade package is " / preload / app / name1", and the path of application Name2 in the OTA upgrade package is " / preload / app / name2"). This application embodiment does not limit the specific content of the blacklist generated by the pre-installed platform.
[0331] S406. Pre-installation operators configure in TRC whether pre-installation packages support pre-installation for different user groups.
[0332] Pre-installation operations personnel access the TRC platform to configure whether the pre-installation package has the capability for pre-installation by specific user groups. This function can be disabled to mitigate risks in scenarios where traffic is too high and the pre-installation platform cannot support it, as shown in Figure 11.
[0333] Figure 11 illustrates whether the pre-installation package has the capability for segmented pre-installation on the cloud side. The cloud side is the TRC platform. The TRC platform allows configuration of whether the pre-installation package is segmented for different user groups. If the pre-installation operator on the TRC platform selects the segmented pre-installation option (e.g., clicks the "Confirm Segmentation" button), the pre-installation package supports segmented pre-installation. If the operator does not select the segmented pre-installation option (e.g., does not click the "Confirm Segmentation" button), the pre-installation package does not support segmented pre-installation. Figure 11 only illustrates the example of the operator on the TRC platform selecting the segmented pre-installation option.
[0334] S407.TRC updates pre-installed package configuration.
[0335] After the pre-installation operator determines the configuration of the pre-installation package in the TRC platform, the TRC platform can automatically update the pre-installation package settings. As shown in Figure 11, the pre-installation operator can set other parameters in the pre-installation package, such as device type, software platform version, software type, etc. This application embodiment does not limit the parameters for configuring the pre-installation package in TRC.
[0336] The TRC platform can obtain network traffic from pre-installed service platforms. When the network traffic obtained by the TRC platform from the pre-installed service platform exceeds the tolerance threshold (e.g., the network traffic limit of the pre-installed service platform), it can modify the pre-installation options for different user groups in the pre-installation package (e.g., setting the pre-installation package to not support pre-installation for different user groups).
[0337] Before the terminal device undergoes an OTA upgrade, the terminal device has already downloaded the OTA upgrade package, which contains pre-installed configuration files for different user groups and installation packages for all pre-installed applications.
[0338] During OTA (Over-The-Air) upgrades on terminal devices, the terminal device obtains a list of pre-installed applications from the pre-installed service platform. The PMS (Program Management System) module loads the installation package and matches the pre-installed application list when executing the installation task. Since the number of applications that are fully installed (applications required by all users in the OTA package) is greater than the number of applications pre-installed by different user groups, the data volume of the pre-installed application list in blacklist format is smaller than that in whitelist format. Therefore, the pre-installed service platform returning a blacklist format of pre-installed applications to the terminal device can reduce the amount of data during end-to-end cloud interaction.
[0339] The PMS uses a blacklist to determine whether pre-installed applications need to be installed, which can reduce the matching workload of the PMS on the terminal device. For example, there are 12 pre-installed application installation packages in the OTA upgrade package. After analysis by the pre-installation service platform, the terminal device needs to install 11 applications other than the one named "Name12", and does not need to install the application named "Name12". An example of PMS matching blacklists and whitelists on the terminal device is shown in Figure 12.
[0340] As shown in Figure 12, if a whitelist is used, the PMS module, when installing software, first needs to obtain the application installation package from the OTA package, parse the application name, and determine whether the application name is in the whitelist. If the PMS module determines that the application name is in the whitelist, it executes the installer to install the application. In the worst case, the PMS module performs 132 checks to determine whether the application name is in the whitelist.
[0341] If a blacklist is used, the PMS module, when installing software, first needs to obtain the application installation package from the OTA package, parse the application name, and determine whether the application name is in the blacklist. If the PMS module determines that the application name is not in the blacklist, it executes the installer to install the application. In the worst case, the PMS module performs 12 checks to determine if the application name is in the blacklist. Since the number of pre-installed applications that are fully installed is greater than the number of applications pre-installed by different user groups, using a blacklist to determine whether pre-installed applications are installed reduces the PMS's matching workload.
[0342] Using a blacklist of pre-installed applications on terminal devices can reduce the amount of data exchanged between the terminal device and the cloud during OTA upgrades; it can also reduce the workload of the PMS module in the terminal device during installation, thereby shortening the OTA upgrade time and improving the user experience.
[0343] During the upgrade, if the pre-installed service platform experiences excessive surge traffic, the TRC platform can be used to disable the pre-installed application function for specific user groups, protecting the cloud platform devices. Specifically, the TRC platform can acquire network traffic data from the pre-installed service platform and either allow pre-installation operators to proactively disable the pre-installed application function for a specific user group, or automatically disable the pre-installed application function for that user group if the network traffic exceeds a threshold (such as the network traffic limit for the pre-installed service platform). This application embodiment does not limit the specific method by which the TRC platform disables the pre-installed application function for specific user groups.
[0344] Figure 13 illustrates the hardware structure of a terminal device provided in an embodiment of this application. This terminal device is used to execute the method for pre-installing applications for different user groups provided in the preceding method embodiments.
[0345] The terminal device 100 may include: a processor 110, an internal memory 121, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, and a display screen 194, etc. The sensor module 180 may include a touch sensor 180K, etc.
[0346] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the terminal device 100. In other embodiments of this application, the terminal device 100 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.
[0347] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.
[0348] The controller can serve as the central nervous system and command center of the terminal device 100. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.
[0349] 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 the efficiency of the system.
[0350] The processor 110 can execute the methods implemented by the terminal device as shown in Figures 2A to 12 above.
[0351] The wireless communication function of the terminal device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.
[0352] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in terminal device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.
[0353] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the terminal device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.
[0354] The wireless communication module 160 can provide solutions for wireless communication applications on the terminal device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks) and Bluetooth (BT). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, demodulates and filters the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, frequency-modulate and amplify them, and then convert them into electromagnetic waves for radiation via antenna 2.
[0355] Terminal device 100 can download OTA upgrade packages through mobile communication module 150 and / or wireless communication module 160. Terminal device 100 can also establish a wireless connection with the pre-installed service platform through mobile communication module 150 and / or wireless communication module 160, and can also establish a wireless connection with the image platform through mobile communication module 150 and / or wireless communication module 160, and perform the method described in Figures 2A to 12 above for establishing a wireless connection between the terminal device and the pre-installed service platform and the image platform, and transmitting data based on the wireless connection.
[0356] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD). The display panel can also be manufactured using organic light-emitting diodes (OLEDs), active-matrix organic light-emitting diodes (AMOLEDs), flexible light-emitting diodes (FLEDs), miniled, microLEDs, micro-OLEDs, quantum dot light-emitting diodes (QLEDs), etc. In some embodiments, terminal device 100 may include one or N displays 194, where N is a positive integer greater than 1.
[0357] The terminal device 100 can display the display interface of the terminal device 100 as shown in FIG2A through the display screen 194.
[0358] Internal memory 121 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM).
[0359] Random access memory can include static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM, for example, fifth generation DDR SDRAM is generally called DDR5SDRAM), etc.
[0360] Non-volatile memory can include disk storage devices and flash memory.
[0361] The random access memory can be directly read and written by the processor 110. It can be used to store executable programs (such as machine instructions) of the operating system or other running programs, as well as user and application data.
[0362] Non-volatile memory can also store executable programs and user and application data, and can be pre-loaded into random access memory for direct reading and writing by the processor 110.
[0363] 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 "touch screen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor 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 terminal device 100, in a different position than display screen 194.
[0364] It should be understood that the steps in the above-described method embodiments provided in this application can be implemented by integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.
[0365] This application also provides a computer program product comprising: a computer program (also referred to as code or instructions) that, when run, causes a computer to perform the method executed by the terminal device in any of the above embodiments.
[0366] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the method executed by the terminal device in any of the foregoing embodiments.
[0367] This application also provides a chip system including at least one processor for implementing the functions involved in the methods performed by the electronic device in any of the above embodiments.
[0368] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located inside or outside the processor.
[0369] The chip system can consist of chips or include chips and other discrete components.
[0370] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.
[0371] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application embodiment does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application embodiment does not specifically limit the type of memory or the arrangement of the memory and processor.
[0372] For example, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.
[0373] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.
[0374] In the foregoing 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 program instructions are loaded and executed on a computer, all or part of the processes or functions described in 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 website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) 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 medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk).
[0375] Those skilled in the art will understand that implementing all or part of the processes in the foregoing embodiments can be accomplished by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the foregoing method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as read-only memory (ROM) or random access memory (RAM), magnetic disks, or optical disks.
[0376] In summary, the above description is merely an embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the disclosure of this application should be included within the scope of protection of this application.
Claims
1. A method for installing an application, the method being applied to an electronic device, characterized in that, The method includes: Obtain the first upgrade package, which includes installation packages for N applications; Send a first message to the server, the first message being used by the server to determine M applications out of the N applications, where M is less than or equal to N, and M and N are positive integers; Receive a first application list returned by the server, the first application list including the M applications; If the first application list is a whitelist, then install the M applications according to the first application list; If the first application list is a blacklist, then install the NM applications according to the first application list.
2. The method according to claim 1, characterized in that, The first upgrade package includes a first identifier, and sending the first message to the server includes: The first message is sent to the server based on the first identifier.
3. The method according to claim 1 or 2, characterized in that, The first message includes a first version, which is the version of the first upgrade package. The first version is used by the server to determine the N applications based on the first version.
4. The method according to any one of claims 1-3, characterized in that, The first message includes a first user identifier, which is used by the server to identify the M applications, and the M applications are associated with the first user identifier.
5. The method according to any one of claims 1-4, characterized in that, The method includes: The first interface displays the application icon or application card of the first application, and the M applications include the first application.
6. A method for installing an application, the method being applied to a server, characterized in that, The method includes: The device receives a first message sent by an electronic device. The first message is used to identify M applications out of N applications. The N applications are the applications corresponding to the first upgrade package obtained by the electronic device, where M is less than or equal to N, and M and N are positive integers. The first application list is determined based on the first message; The first application list, which includes the M applications, is sent to the electronic device. If the first application list is a whitelist, then the first application list is used to instruct the electronic device to install the M applications. If the first application list is a blacklist, then the first application list is used to instruct the electronic device to install the NM applications.
7. The method according to claim 6, characterized in that, The first message includes a first version, which is the version of the first upgrade package, and the method includes: The N applications are determined based on the first version.
8. The method according to claim 6 or 7, characterized in that, The first message also includes a first user identifier, and the method includes: The M applications are identified by the first user identifier, and the M applications are associated with the first user identifier.
9. The method according to claim 8, characterized in that, The server stores the user tags of the electronic devices, and the server sets a correspondence between the user tags and the applications installed on the electronic devices; The step of identifying the M applications through the first user identifier includes: The user identifier is used to obtain the user tag of the electronic device, and the M applications corresponding to the user tag are determined.
10. A method for installing an application, characterized in that, The method is applied to a first communication system, the first communication system comprising: an electronic device and a server; the method includes: The electronic device acquires a first upgrade package, which includes installation packages for N applications; The server receives a first message sent by the electronic device to determine a first application list. The first message is used to determine M applications out of the N applications, where M is less than or equal to N, and M and N are positive integers. The server sends the first application list to the electronic device, the first application list including the M applications; If the first application list is a whitelist, the server installs the M applications according to the first application list; If the first application list is a blacklist, the server installs the NM applications according to the first application list.
11. The method according to claim 10, characterized in that, The first upgrade package includes a first identifier, and the electronic device sending the first message to the server includes: The electronic device sends the first message to the server based on the first identifier.
12. The method according to claim 10 or 11, characterized in that, The first message includes a first version, which is the version of the first upgrade package, and the method includes: The server determines the N applications based on the first version.
13. The method according to any one of claims 10-12, characterized in that, The first message also includes a first user identifier, and the method includes: The server identifies the M applications through the first user identifier, and the M applications are associated with the first user identifier.
14. The method according to claim 13, characterized in that, The server stores the user tags of the electronic devices, and the server sets a correspondence between the user tags and the applications installed on the electronic devices; The server identifies the M applications using the first user identifier, including: The server obtains the user tag of the electronic device through the first user identifier and determines the M applications corresponding to the user tag.
15. The method according to any one of claims 10-14, characterized in that, The method includes: The electronic device displays the application icon or application card of the first application on the first interface, and the M applications include the first application.
16. An electronic device, characterized in that, The electronic device includes one or more memories and one or more processors; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-5.
17. A communication system, comprising electronic equipment and a server, characterized in that, The electronic device has a communication connection with the server, the electronic device performs the method as described in any one of claims 10-15, and the server performs the method as described in any one of claims 10-15.
18. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by a processor, the computer instructions implement the method of any one of claims 1-5, or perform the method of any one of claims 6-9, or perform the method of any one of claims 10-15.
19. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method steps of any one of claims 1-5, or to implement the method of any one of claims 6-9, or to implement the method of any one of claims 10-15.
20. A chip, characterized in that, The chip stores a computer program, which, when executed by the chip, implements the method as described in any one of claims 1-5, or performs the method as described in any one of claims 6-9, or performs the method as described in any one of claims 10-15.
Citation Information
Patent Citations
Application installation control method, related system and related device
CN103646215A
Preinstalled application management method and device and storage medium
CN109683949A
Pre-installed application software management method and terminal
CN111221544A
Method and system for downloading customized application
CN113727333A
Method and system for limiting installation of specified application program, terminal and storage medium
CN113779557A