CN113727333B - 定制应用的下载系统 - Google Patents

定制应用的下载系统 Download PDF

Info

Publication number
CN113727333B
CN113727333B CN202110876561.8A CN202110876561A CN113727333B CN 113727333 B CN113727333 B CN 113727333B CN 202110876561 A CN202110876561 A CN 202110876561A CN 113727333 B CN113727333 B CN 113727333B
Authority
CN
China
Prior art keywords
application
customized
custom
server
electronic equipment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110876561.8A
Other languages
English (en)
Other versions
CN113727333A (zh
Inventor
李树彬
赵宇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202110876561.8A priority Critical patent/CN113727333B/zh
Publication of CN113727333A publication Critical patent/CN113727333A/zh
Application granted granted Critical
Publication of CN113727333B publication Critical patent/CN113727333B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Stored Programmes (AREA)

Abstract

本申请实施例提供了一种定制应用的下载系统，通过由终端厂商服务器根据运营商的定制需求，确定能够体现不同型号的电子设备对应的市场类型、运营商类型和需要安装的定制应用的定制应用清单，并将定制应用清单单独存储到可与电子设备进行交互的查询服务器，从而在确定电子设备满足预装条件时，向电子设备推送匹配的目标定制应用清单，进而显示可供用户查看的定制应用清单列表，使用户能够自主选择需要的定制应用，并从仅存储运营商提供的需要安装的定制应用的源文件的独立应用存储服务器获取用户选中的定制应用的源文件，而无需获取运营商提供的集所有定制应用的源文件和定制参数资源于一体的定制OTA包，不仅便于维护，也提升了用户体验。

Description

定制应用的下载系统
技术领域
本申请实施例涉及终端领域，尤其涉及一种定制应用的下载系统。
背景技术
随着通信技术的发展，电子设备（例如膝上型计算机、桌上型计算机、掌上型计算机（如平板电脑、智能手机等）等）功能越来越丰富。以手机为例，目前手机生产厂商通常会根据运营商的定制需求为手机安装定制的应用程序（Application，APP，后续统一称作“应用”）。
传统的定制过程，一般是依赖于产线刷机来实现，这种定制方式虽然可以为手机装入运营商需要的定制应用，但是当面临运营商定制的手机数量庞大，如成千上万台时，单纯依赖产线刷机的方式需要大量的人力物力，其成本高、耗时长且迭代升级困难。
为了解决这一问题，目前提供了一种基于定制空中下载（Over-the-Air，OTA）包的定制应用的下载方法，该方法是将运营商提供的所有定制应用的安卓应用程序包（Androidapplication package，APK）（如APK1、APK2...）和装机/更新应用所需的参数资源一起打包成一个定制OTA包，当检测到手机满足预设条件（如首次开机触发开机向导）时，存储定制OTA包的云端服务器会向手机推送整个定制OTA包，使手机安装定制OTA包中所有的定制应用。这种方式虽然可以解决现有依赖产线刷机存在的需要大量人力物力的问题，但是由于云端服务器是采用的通用模式向手机推送定制OTA包，即接入同一运营商网络的多个手机，安装的都是相同的定制应用，无法因人而异。并且，由于该方式的下载方法，是将运营商提供的所有定制应用的安装包（如APK1、APK2...）和装机/更新应用所需的参数资源一起打包成一个定制OTA包，因此当运营商的定制需求发生改变，导致原本定制OTA包中某些应用的APK需要删除，或者进行版本更新，或者增加新的应用的APK时，云端服务器均需重新打包一个完整的定制OTA更新包，然后将发生变化的定制OTA更新包推送给手机，使手机根据接收到的定制OTA更新包对本地已有的应用进行全部的替换。
显然，这种方式不仅会导致维护难度大，也会导致更新耗时长，并且用户体验欠佳的问题。
发明内容
为了解决上述技术问题，本申请提出了一种定制应用的下载系统。在该方法中，通过将终端厂商服务器根据运营商提供的定制需求生成的针对不同型号的电子设备、对应的市场类型、运营商类型和需要安装的定制应用的描述信息对应的定制应用清单存储到查询服务器，从而在查询服务器与电子设备进行交互时，只需向电子设备推送匹配的定制应用清单，而不推送具体的源文件，在用户确定下载定制应用清单中的定制应用时，单独从存储定制应用的源文件的独立应用存储服务器获取用户选中的定制应用的源文件，从而无需获取运营商提供的集所有定制应用的源文件和定制参数资源于一体的定制OTA包，这样即便于维护，又降低了下载时耗，同时用户有选择下载定制应用的权利，大大提升了用户体验。
第一方面，提供一种定制应用的下载系统。该系统包括：终端厂商服务器、查询服务器、独立应用存储服务器和电子设备，所述终端厂商服务器分别与所述查询服务器和所述独立应用存储服务器进行数据交互，所述电子设备分别与所述查询服务器和所述独立应用存储服务器进行数据交互，所述查询服务器和所述独立应用存储服务器进行数据交互，所述电子设备由终端厂商根据运营商的定制需求定制；所述独立应用存储服务器，用于：存储运营商发布的定制应用对应的源文件；以及，根据所述电子设备的请求向所述电子设备推送所述电子设备请求的定制应用对应的源文件；所述终端厂商服务器，用于：根据运营商提供的定制需求，确定不同型号的所述电子设备对应的市场类型、运营商类型和需要安装的定制应用；从所述独立应用存储服务器获取需要安装的所述定制应用对应的源文件的描述信息；建立不同型号的所述电子设备对应的所述市场类型、所述运营商类型和需要安装的所述定制应用的所述描述信息之间的映射关系，得到不同型号的所述电子设备对应的定制应用清单；将所述定制应用清单发送至所述查询服务器进行存储；所述查询服务器，用于：存储所述终端厂商服务器提供的所述定制应用清单；所述电子设备，用于：在满足预装运营商发布的定制应用的预设条件时，获取本机信息，确定本机的型号、投入的市场类型和接入的运营商类型；根据本机的所述型号、投入的所述市场类型和接入的所述运营商类型生成预装请求，并向所述查询服务器发送所述预装请求；所述查询服务器，还用于：根据所述预装请求中携带的所述电子设备的所述型号、投入的所述市场类型和接入的所述运营商类型，从多个所述定制应用清单中匹配出需要发送给所述电子设备的目标定制应用清单，并向所述电子设备推送所述目标定制应用清单；所述电子设备，还用于：根据所述目标定制应用清单显示可供用户查看的定制应用清单列表，所述定制应用清单列表中显示了可供下载的定制应用对应的描述信息；在监测到对所述定制应用清单列表中任一可供下载的所述定制应用的选中操作后，向所述独立应用存储服务器请求被选中的所述定制应用的源文件；接收所述独立应用存储服务器下发的被选中的所述定制应用的源文件，并安装。这样，终端厂商服务器根据运营商的定制需求，确定能够体现不同型号的电子设备对应的市场类型、运营商类型和需要安装的定制应用的定制应用清单，并将定制应用清单单独存储到可与电子设备进行交互的查询服务器，从而在确定电子设备满足预装条件时，向电子设备推送匹配的目标定制应用清单，进而显示可供用户查看的定制应用清单列表，使用户能够自主选择需要的定制应用，并从仅存储运营商提供的需要安装的定制应用的源文件的独立应用存储服务器获取用户选中的定制应用的源文件，而无需获取运营商提供的集所有定制应用的源文件和定制参数资源于一体的定制OTA包，不仅便于维护，也提升了用户体验。
示例性的，电子设备可以为手机、平板电脑等能够安装定制应用的电子设备。
示例性的，源文件的描述信息包括但不限于定制应用的名称、图标、大小等信息。
示例性的，市场类型包括但不限于国内市场和海外市场。
示例性的，运营商类型为电子设备可以接入的运营商。
示例性的，定制需求也可以来自其他客户渠道。
根据第一方面，所述查询服务器，还用于：按照预设周期从独立应用存储服务器获取运营商提供的新的定制应用对应的源文件的描述信息，根据新的所述定制应用对应的源文件的描述信息对所述定制应用清单进行更新；和/或，按照预设周期从所述独立应用存储服务器获取发生变更的源文件对应的描述信息，并根据发生变更的所述源文件对应的描述信息更新本地存储的所述定制应用清单中对应的描述信息。这样，查询服务器便能够周期性的从独立应用存储服务器获取影响定制应用清单准确性的源文件的描述信息，并根据获取到的源文件的描述信息及时更新本地存储的定制应用清单中对应的描述信息，从而保证为电子设备匹配出的目标定制应用清单为最新的定制应用清单。
根据第一方面，或者以上第一方面的任意一种实现方式，所述独立应用存储服务器，还用于：在检测到运营商提供了新的定制应用对应的源文件时，向所述查询服务器发送新的定制应用对应的源文件的描述信息，供所述查询服务器根据新的所述定制应用对应的源文件的描述信息对所述定制应用清单进行更新；和/或，在检测到已存储的所述定制应用对应的源文件发生变更，向所述查询服务器发送发生变更的源文件对应的描述信息，供所述查询服务器根据发生变更的所述源文件对应的描述信息更新本地存储的所述定制应用清单中对应的描述信息。这样，由独立应用存储服务器在存储的源文件发生变更或新增了未存储过的源文件时，主动向查询服务器推送变更的源文件的描述信息和新增的源文件的描述信息，从而无需查询服务器频繁向独立应用存储服务器发起请求，减少了对查询服务器和独立应用存储服务器的资源的占用，并且由独立应用存储服务器主动推送描述信息，能够更加准确的保证查询服务器中存储的定制应用清单的准确性。
根据第一方面，或者以上第一方面的任意一种实现方式，所述独立应用存储服务器，还用于：在向所述电子设备推送所述电子设备请求的定制应用对应的源文件时，记录推送时间和推送结果；根据所述推送时间、所述推送结果、所述源文件的描述信息和所述电子设备的标示信息，生成日志信息。这样，电子设备每次从独立应用存储服务器中下载定制应用的源文件时，便可以记录哪一电子设备（根据电子设备的标示信息，如出厂号等）在哪一时刻下载了哪个定制应用的哪个版本，以及是否下载成功等日志信息，以便后续维护更新。
根据第一方面，或者以上第一方面的任意一种实现方式，所述终端厂商服务器，还用于：根据运营商提供的定制需求，生成所述电子设备安装所述定制应用时采用的定制布局文件；建立所述定制布局文件与所述定制应用清单的之间的第一映射关系，得到映射关系表；将所述定制布局文件和所述映射关系表发送至所述查询服务器；所述查询服务器，还用于：根据所述映射关系表中记录的所述第一映射关系，将所述定制布局文件与所述定制应用清单进行绑定，并在向所述电子设备推送所述目标定制应用清单时，向所述电子设备推送绑定的所述定制布局文件。这样，实现了定制应用清单与定制布局文件的匹配，并且通过将二者进行绑定，使得查询服务器能够在推送适合电子设备的目标定制应用清单时，一同将匹配的定制布局文件推送给电子设备，减少了二者之间不必要的请求次数。
根据第一方面，或者以上第一方面的任意一种实现方式，所述终端厂商服务器，还用于：根据运营商提供的定制需求，确定需要配置到所述电子设备中的定制参数资源；建立所述定制参数资源与所述定制应用清单之间的第二映射关系，并将所述第二应关系添加到所述映射关系表；将所述定制参数资源和所述映射关系表发送至所述查询服务器；所述查询服务器，还用于：根据所述映射关系表中记录的所述第二映射关系，将所述定制参数资源与所述定制应用清单进行绑定，并在向所述电子设备推送所述目标定制应用清单时，向所述电子设备推送绑定的所述定制参数资源。这样，实现了定制应用清单与定制参数资源，或者定制应用清单与定制布局文件以及定制参数资源之间的匹配，并且通过将定制应用清单与定制参数资源二则进行绑定，或者定制应用清单与定制布局文件以及定制参数资源三者进行绑定，使得查询服务器能够在推送适合电子设备的目标定制应用清单时，一同将匹配的定制布局文件、定制参数资源推送给电子设备，减少了二者之间不必要的请求次数。
根据第一方面，或者以上第一方面的任意一种实现方式，所述终端厂商服务器，还用于：根据运营提供的定制需求，确定需要安装的所述定制应用对应的权限信息；根据所述权限信息更新所述定制应用清单，并将更新后的所述定制应用清单发送至所述查询服务器；所述查询服务器，还用于：根据所述权限信息，确定推送给所述电子设备的所述目标定制应用清单中可供用户选择的定制应用和默认需要安装的定制应用。这样，终端厂商服务器便可以根据运营商的定制需求，为特定的定制应用设置特定的权限信息，比如通过将某个定制应用的权限设置为必须下载且不可删除的权限，则电子设备在显示定制应用清单列表时，设置了上述权限信息的定制应用，默认就是被选中需要下载的，而未设置此类权限信息的定制应用则是可以提供给用户自主选择的，从而既能保证运营商要求的特定的定制应用被安装到电子设备，又能为用户提供自主选择的权利，提升了用户参与度。
根据第一方面，或者以上第一方面的任意一种实现方式，所述终端厂商服务器，还用于：统计并存储被运营商指定为定制应用的应用信息。这样，终端厂商便可以获取哪些应用经常被哪个运营商指定为定制应用，从而便于后续推广。
根据第一方面，或者以上第一方面的任意一种实现方式，所述独立应用存储服务器的数量为一个。这样，通过将不同运营商提供的定制应用的源文件均存储到一个独立应用存储服务器中，从而可以避免相同源文件的重复存储，并且独立应用存储服务器的数量减少，也能够给降低整体的实现成本，便于产品落地。
根据第一方面，或者以上第一方面的任意一种实现方式，所述独立应用存储服务器的数量与提供定制需求的运营商的个数相同，且每一所述独立应用存储服务器对应一个运营商。这样，不同运营商提供的需要安装到电子设备中的定制应用对应的源文件就可以单独保存到各运营商对应的独立应用存储服务器进行存储，从而便于后期对不同运营商的定制应用的源文件的维护。
第二方面，提供一种定制应用的下载方法，应用于定制应用的下载系统，所述系统包括：终端厂商服务器、查询服务器、独立应用存储服务器和电子设备，所述终端厂商服务器分别与所述查询服务器和所述独立应用存储服务器进行数据交互，所述电子设备分别与所述查询服务器和所述独立应用存储服务器进行数据交互，所述查询服务器和所述独立应用存储服务器进行数据交互，所述电子设备由终端厂商根据运营商的定制需求定制；所述方法包括：所述终端厂商服务器根据运营商提供的定制需求，确定不同型号的所述电子设备对应的市场类型、运营商类型和需要安装的定制应用；所述终端厂商服务器从所述独立应用存储服务器获取需要安装的所述定制应用对应的源文件的描述信息；所述终端厂商服务器建立不同型号的所述电子设备对应的所述市场类型、所述运营商类型和需要安装的所述定制应用的所述描述信息之间的映射关系，得到不同型号的所述电子设备对应的定制应用清单；所述终端厂商服务器将所述定制应用清单发送至所述查询服务器进行存储；所述查询服务器存储所述终端厂商服务器提供的所述定制应用清单；所述电子设备在满足预装运营商发布的定制应用的预设条件时，获取本机信息，确定本机的型号、投入的市场类型和接入的运营商类型；所述电子设备根据本机的所述型号、投入的所述市场类型和接入的所述运营商类型生成预装请求，并向所述查询服务器发送所述预装请求；所述查询服务器根据所述预装请求中携带的所述电子设备的所述型号、投入的所述市场类型和接入的所述运营商类型，从多个所述定制应用清单中匹配出需要发送给所述电子设备的目标定制应用清单，并向所述电子设备推送所述目标定制应用清单；所述电子设备根据所述目标定制应用清单显示可供用户查看的定制应用清单列表，所述定制应用清单列表中显示了可供下载的定制应用对应的描述信息；所述电子设备在监测到对所述定制应用清单列表中任一可供下载的所述定制应用的选中操作后，向所述独立应用存储服务器请求被选中的所述定制应用的源文件；所述独立应用存储服务器根据所述电子设备的请求向所述电子设备推送所述电子设备请求的定制应用对应的源文件；所述电子设备接收所述独立应用存储服务器下发的被选中的所述定制应用的源文件，并安装。
根据第二方面，所述方法还包括：所述查询服务器按照预设周期从独立应用存储服务器获取运营商提供的新的定制应用对应的源文件的描述信息，根据新的所述定制应用对应的源文件的描述信息对所述定制应用清单进行更新；和/或，所述查询服务按照预设周期从所述独立应用存储服务器获取发生变更的源文件对应的描述信息，并根据发生变更的所述源文件对应的描述信息更新本地存储的所述定制应用清单中对应的描述信息。
根据第二方面，或者以上第二方面的任意一种实现方式，所述方法还包括：所述独立应用存储服务器在检测到运营商提供了新的定制应用对应的源文件时，向所述查询服务器发送新的定制应用对应的源文件的描述信息，供所述查询服务器根据新的所述定制应用对应的源文件的描述信息对所述定制应用清单进行更新；和/或，所述独立应用存储服务器在检测到已存储的所述定制应用对应的源文件发生变更，向所述查询服务器发送发生变更的源文件对应的描述信息，供所述查询服务器根据发生变更的所述源文件对应的描述信息更新本地存储的所述定制应用清单中对应的描述信息。
根据第二方面，或者以上第二方面的任意一种实现方式，所述方法还包括：所述独立应用存储服务器在向所述电子设备推送所述电子设备请求的定制应用对应的源文件时，记录推送时间和推送结果；根据所述推送时间、所述推送结果、所述源文件的描述信息和所述电子设备的标示信息，生成日志信息。
根据第二方面，或者以上第二方面的任意一种实现方式，所述方法还包括：所述终端厂商服务器根据运营商提供的定制需求，生成所述电子设备安装所述定制应用时采用的定制布局文件；所述终端厂商服务器建立所述定制布局文件与所述定制应用清单的之间的第一映射关系，得到映射关系表；所述终端厂商服务器将所述定制布局文件和所述映射关系表发送至所述查询服务器；所述查询服务器根据所述映射关系表中记录的所述第一映射关系，将所述定制布局文件与所述定制应用清单进行绑定，并在向所述电子设备推送所述目标定制应用清单时，向所述电子设备推送绑定的所述定制布局文件。
根据第二方面，或者以上第二方面的任意一种实现方式，所述方法还包括：所述终端厂商服务器根据运营商提供的定制需求，确定需要配置到所述电子设备中的定制参数资源；所述终端厂商服务器建立所述定制参数资源与所述定制应用清单之间的第二映射关系，并将所述第二应关系添加到所述映射关系表；所述终端厂商服务器将所述定制参数资源和所述映射关系表发送至所述查询服务器；所述查询服务器根据所述映射关系表中记录的所述第二映射关系，将所述定制参数资源与所述定制应用清单进行绑定，并在向所述电子设备推送所述目标定制应用清单时，向所述电子设备推送绑定的所述定制参数资源。
根据第二方面，或者以上第二方面的任意一种实现方式，所述方法还包括：所述终端厂商服务器根据运营提供的定制需求，确定需要安装的所述定制应用对应的权限信息；所述终端厂商服务器根据所述权限信息更新所述定制应用清单，并将更新后的所述定制应用清单发送至所述查询服务器；所述查询服务器根据所述权限信息，确定推送给所述电子设备的所述目标定制应用清单中可供用户选择的定制应用和默认需要安装的定制应用。
根据第二方面，或者以上第二方面的任意一种实现方式，所述方法还包括：所述终端厂商服务器统计并存储被运营商指定为定制应用的应用信息。
根据第二方面，或者以上第二方面的任意一种实现方式，所述独立应用存储服务器的数量为一个。
根据第二方面，或者以上第二方面的任意一种实现方式，所述独立应用存储服务器的数量与提供定制需求的运营商的个数相同，且每一所述独立应用存储服务器对应一个运营商。
第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第三方面，提供了一种应用的下载系统，包括：查询服务器、存储服务器和电子设备，所述电子设备分别与所述查询服务器和所述存储服务器进行数据交互，所述查询服务器和所述存储服务器进行数据交互；所述存储服务器，用于：存储可供电子设备安装的应用对应的源文件；以及，根据所述电子设备的请求向所述电子设备推送所述电子设备请求的应用对应的源文件；所述查询服务器，用于：获取所述存储服务器存储的所述应用对应的源文件的描述信息和所述源文件对应的地址信息，并建立所述描述信息和所述地址信息之间的映射关系；根据所述映射关系，向发起搜索请求的所述电子设备推送需要安装的所述应用的源文件所在的地址信息；所述电子设备，用于：向所述查询服务器发起搜索需要安装的应用的搜索请求，所述搜索请求携带了需要安装的所述应用的描述信息；从所述查询服务器反馈的所述地址信息对应的存储服务器获取需要安装的所述应用的源文件。这样，通过在查询服务器中提供各种可以安装在电子设备中的应用的源文件的描述信息与源文件对应的地址信息之间的映射关系，使得电子设备始终可以获取到需要安装的应用的源文件的地址信息，进而根据地址信息从对应的存储服务器获取源文件实现安装，解决了现有用户使用一个应用商店对应的查询服务器只能获取到该应用商店对应的存储服务器中存储的应用的源文件的技术问题。
根据第三方面，所述存储服务器为终端厂商服务器，所述存储服务器中存储的源文件为终端厂商提供的应用的源文件。这样，实现了终端厂商自己发布的应用的独立管理与维护。
根据第三方面，或者以上第三方面的任意一种实现方式，所述存储服务器为运营商服务器，所述存储服务器中存储的源文件为运营商提供的定制应用的源文件。这样，实现了对运营商定制应用的独立管理与维护。
根据第三方面，或者以上第三方面的任意一种实现方式，所述存储服务器为第三方应用商服务器，所述存储服务器中存储的源文件为第三方应用对应的源文件。这样，实现了对第三方应用的独立管理与维护。
根据第三方面，或者以上第三方面的任意一种实现方式，所述查询服务器和所述存储服务器为同一个服务器。这样，可以减少服务器的投入成本。
根据第三方面，或者以上第三方面的任意一种实现方式，所述查询服务器和所述存储服务器为不同的服务器。这样，查询服务器和存储服务器可以分别管理维护。
第四方面，提供了一种应用的下载方法，应用于应用的下载系统，所述系统包括：询服务器、存储服务器和电子设备，所述电子设备分别与所述查询服务器和所述存储服务器进行数据交互，所述查询服务器和所述存储服务器进行数据交互；所述方法包括：所述电子设备根据需要安装的应用的描述信息生成搜索请求，并向所述查询服务器发起所述搜索请求；所述查询服务器接收到所述搜索请求后，根据所述搜索请求中携带的需要安装的所述应用的描述信息查找本地存储的可供所述电子设备安装的应用对应的源文件的描述信息，确定目标描述信息；所述查询服务器根据记录了所述可供所述电子设备安装的应用对应的源文件的描述信息与所述源文件对应的地址信息的映射关系，确定与所述目标描述信息对应的源文件存在映射关系的目标地址信息；所述查询服务器向所述电子设备下发所述目标地址信息；所述电子设备从所述查询服务器反馈的所述目标地址信息对应的存储服务器获取需要安装的所述应用的源文件。这样，通过在查询服务器中提供各种可以安装在电子设备中的应用的源文件的描述信息与源文件对应的地址信息之间的映射关系，使得电子设备始终可以获取到需要安装的应用的源文件的地址信息，进而根据地址信息从对应的存储服务器获取源文件实现安装，解决了现有用户使用一个应用商店对应的查询服务器只能获取到该应用商店对应的存储服务器中存储的应用的源文件的技术问题。
根据第四方面，在所述存储服务器中存储有需要安装的所述应用的源文件时，所述目标地址信息为所述存储服务器的地址信息。这样，电子设备便可以直接从存储服务器获取需要安装的应用的源文件。
根据第四方面，或者以上第四方面的任意一种实现方式，在所述存储服务器中未存储需要安装的所述应用的源文件时，所述目标地址信息为所述源文件所在的源站的地址信息。这样，即便当前的存储服务器中没有存在电子设备搜索的需要安装的应用的源文件，查询服务器也可以向电子设备返回需要安装的应用的源文件实际所在的源站的地址信息，从而使得电子设备能够根据返回的源站的地址信息，直接跳转到源站下载需要安装的应用的源文件。
第五方面，提供一种计算机可读存储介质。该介质包括计算机程序，当计算机程序在电子设备或服务器上运行时，使得电子设备或服务器执行第二方面以及第二方面中任意一项中的定制应用的下载方法。示例性的，服务器可以为终端厂商服务器，或查询服务器，或独立应用存储服务器。
示例性的，当计算机程序在电子设备或服务器上运行时，是的电子设备或服务器执行第四方面以及第四方面中任一项中的定制应用的下载方法。示例性的，服务器可以为查询服务器或存储服务器。
第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应，或者与第三方面以及第三方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，或者第三方面以及第三方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第六方面，本申请实施例提供了一种计算机程序，该计算机程序包括用于执行第二方面或第二方面的任意可能的实现方式中的方法的指令，或者第四方面或第四方面的任意可能的实现方式中的方法的指令。
第六方面以及第六方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应，或者与第三方面以及第三方面的任意一种实现方式相对应。第六方面以及第六方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，或者第三方面以及第三方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第七方面，本申请实施例提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第二方面或第二方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。示例性的，芯片可以为服务器的芯片或电子设备的芯片，服务器可以为终端厂商服务器，或查询服务器，或独立应用存储服务器。
示例性的，芯片中处理器还可以执行第二方面或第二方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。示例性的，芯片可以为服务器的芯片或电子设备的芯片，服务器可以为查询服务器，或存储服务器。
第七方面以及第七方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应，或者与第三方面以及第三方面的任意一种实现方式相对应。第七方面以及第七方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，或者第三方面以及第三方面的任意一种实现方式所对应的技术效果，此处不再赘述。
附图说明
图1 是示例性示出的现有云端服务器向端侧推送运营商定制应用的示意图；
图2是示例性示出的现有云端服务器向端侧推送运营商定制应用的场景示意图；
图3是示例性示出的手机的结构示意图；
图4是示例性示出的手机的软件结构示意图；
图5是示例性示出的本申请实施例提供的定制应用的下载方法的涉及的系统架构示意图；
图6是示例性示出的本申请实施例提供的定制应用的下载方法的应用场景示意图；
图7是示例性示出的云端、平台侧和端侧实现本申请实施例提供的定制应用的下载方法的交互示意图；
图8是示例性示出的基于运营商的定制需求将定制内容按照本申请实施例提供的定制应用的下载方法分别存储到查询服务器和独立应用存储服务器的示意图；
图9是示例性示出的定制应用的源文件、定制应用清单、定制应用布局文件的配置和发布管理的示意图；
图10a是示例性示出的未安装过定制应用时应用版本检测提醒的流程示意图；
图10b是示例性示出的未安装过定制应用时应用版本检测提醒的又一流程示意图；
图11a是示例性示出的安装过定制应用时应用版本检测提醒的流程示意图；
图11b是示例性示出的安装过定制应用时应用版本检测提醒的又一流程示意图；
图12a是示例性示出的在锁屏状态时检测到定制应用更新版本后显示的通知界面图；
图12b是示例性示出的在主界面时检测到定制应用更新版本后显示的通知界面图；
图13a是示例性示出的手机根据查询服务器推送的用意列表清单信息显示可供选择的运营商应用程序的示意图；
图13b是示例性示出的应用场景示意图；
图13c是示例性示出的应用场景示意图；
图14是示例性示出的本申请实施例提供的定制应用的下载方法中定制应用的下载及安装的流程示意图；
图15a是示例性示出的手机从独立应用存储服务器获取需要下载的定制应用的示意图；
图15b是示例性示出的手机正在安装从独立应用存储服务器获取到的定制应用的示意图；
图15c是示例性示出的手机安装成功从独立应用存储服务器获取到的定制应用的示意图；
图16是示例性示出的本申请实施例提供的定制应用的下载方法中定制布局文件的下载及生效的流程示意图；
图17是本申请实施例提供的一种装置的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。
在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。
本申请实施例提供一种应用下载的方法，针对终端厂商根据运营商的定制需求，或者其他渠道客户的定制需求定制的需要预装指定应用的场景。关于这类场景下的应用下载的方法，首先结合图1对现有基于定制OTA包的定制应用的下载方案进行说明。参见图1，基于定制OTA包的定制应用的下载方案，是将运营商提供的所有定制应用的安装包（如定制应用1的APK1、版本为V1的定制应用2的APK2_V1）和装机/更新应用所需的参数资源等需要推送给手机的数据一起打包成一个定制OTA包，如图1中的定制OTA包_0，存储到云端的服务器。
当检测到端侧，如手机满足预设条件时，云端的服务器会将目前存储的定制OTA包_0推送到手机，然后由手机对定制OTA包_0进行解压处理，并依次安装APK1和APK2_V1，进而在手机中完成定制应用1和定制应用2的安装。
可理解的，上述所说的预设条件，可以是检测到用户触发了开机向导功能，或者是服务器检测到了存在定制OTA包，并且有与之建立网络连接的手机。
对于一种场景，如图1中的场景1，若运营商对定制应用2的APK2的版本进行了更新，如更新为了V2版本，则服务器会将更新后的APK2_V2与未发生变化的参数资源、APK1重新打包一个定制OTA包，如图1中的定制OTA包_1。当检测到手机满足预设条件时，服务器将更新后的定制OTA包_1推送到手机，然后由手机对定制OTA包_1进行解压处理，并基于版本更新后的APK2_V2对手机中已安装的定制应用2进行版本更新。虽然无需对未发生变化的定制应用1和参数资源进行更改，但是手机想要更新V2版本的定制应用2，必须要一同获取未发生变化的定制应用1的APK1和参数资源。
可理解的，针对场景1中所说的满足预设条件，可以是服务器检测到有更新的定制OTA包，或者是用户触发了手机界面显示的更新应用的按键、或者检测有待更新或者下载的OTA包之后，向用户推送更新请求，接收用户的确认之后，下载或者更新所述OTA包，或者检测到有待更新的或者下载的OTA包之后，且手机满足预设条件，例如，预设时间段内连接了Wi-Fi或者充电状态下，也可以自动推送OTA包等。
此外，对于另一种应用场景，如图1中的场景2，若运营商的定制需求发生变化，新增了定制应用3的APK3，则服务器需要将定制OTA包_1中的参数资源、APK1和APK2_V2，同APK3一起打包成一个新的定制OTA包，如图1中的定制OTA包_2。当检测到手机满足预设条件时，服务器将更新后的定制OTA包_2推送到手机，然后由手机对定制OTA包_2进行解压处理，并在手机中安装APK3，进而完成新增的定制应用3的安装。虽然无需对未发生变化的定制应用1、V2版本的定制应用2和参数资源进行更改，但是手机想要安装定制应用3，必须要一同获取未发生变化的定制应用1的APK1、定制应用2的APK2_V2和参数资源。
可理解的，针对场景2中所说的满足预设条件，可以是服务器检测到有更新的定制OTA包，或者是用户触发了手机界面显示的搜索定制应用的按键等。
此外，对于另一种应用场景，如图1中的场景3，若运营商的定制需求发生变化，删除定制应用1的APK1，则服务器需要将定制OTA包_2中的参数资源、APK2_V2和APK重新打包成一个新的定制OTA包，如图1中的定制OTA包_3。当检测到手机满足预设条件时，服务器将更新后的定制OTA包_3推送到手机，然后由手机对定制OTA包_3进行解压处理，发现运营商已经不提供定制应用1，此时手机会自动卸载定制应用1。虽然无需对未发生变化的V2版本的定制应用2、定制应用3和参数资源进行更改，但是手机想要卸载定制应用1，必须要一同获取未发生变化的V2版本的定制应用2、定制应用3和参数资源。
可理解的，针对场景2中所说的满足预设条件，可以是服务器检测到有更新的定制OTA包，或者是手机发起了检测服务器是否存在更新的定制OTA包的请求。
为了更好的理解上述所说的应用下载方法，以下结合图2示出的具体应用场景进行说明。
参见图2，假设运营商1提供的定制OTA包为上述所说的包括参数资源、APK1和APK2_V1的定制OTA_0，运营商2提供的定制OTA包为上述所说包括参数资源、APK1、APK2_V2和APK3的定制OTA_2，运营商3提供的定制OTA包为上述所说的包括参数资源、APK2_V2和APK3的定制OTA_3。
那么采用上述所说的应用下载方法，运营商1定制的手机群组中的所有手机在满足预装条件时，都只能从云端服务器获取完整的定制OTA_0，并安装定制OTA_0中的所有应用，即手机A1、手机B1和手机C1中都必须配置参数资源，并安装APK1和APK2_V1。
相应地，运营商2定制的手机群组中的所有手机在满足预装条件时，都只能从云端服务器获取完整的定制OTA_2，并安装定制OTA_2中的所有应用，即手机A2、手机B2和手机C2中都必须配置参数资源，并安装APK1、APK2_V2和APK3。
相应地，运营商3定制的手机群组中的所有手机在满足预装条件时，都只能从云端服务器获取完整的定制OTA_3，并安装定制OTA_3中的所有应用，即手机A3、手机B3和手机C3中都必须配置参数资源，并安装APK2_V2和APK3。
此外，应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际的应用场景中，存储在云端服务器中的定制OTA包，还可能是其他客户渠道提供的，并不局限于运营商。
通过上述描述不难发现，现有基于定制OTA包的定制应用下载方案，对于已经下载，并安装过定制OTA包_0中APK的端侧（如手机），后续提供定制OTA包_0的运营商一旦对其中的某个定制应用的版本进行更新（场景1），或者新增某个定制应用的APK（场景2），或者下线某个定制应用的APK（场景3），手机都需要下载携带所有信息的定制OTA更新包，强制对已安装的应用进行更新，卸载，或者新增某些应用，即现有基于定制OTA包的定制应用下载方案，根本无法实现对特定的用户群进行区别处理，也不能仅下载某一定制应用的APK进行安装、更新等操作。因此这种定制需求一旦发生变化，就需要将所有参数资源和定制应用的APK重新打包成一个定制OTA包的方案，不仅会导致维护难度大，也会导致更新耗时长，并且用户体验欠佳的问题。
示例性的，手机与云端之间可通过蜂窝网络，或无线网络交互数据。需要说明的是，在本申请实施例的描述中，云端包括一个或多个服务器，但这些服务器中均存储的是包括了参数资源和运营商提供的所有定制应用的APK的定制OTA包，用于为端侧的设备提供需要运营商的定制引用。
此外，端侧的手机的数量在实际应用场景中，可以是一个多或多个。
此外，可理解的是，本申请实施例的描述中，是以手机为例进行说明，在其他实施例中，本申请同样适用于大屏、膝上型计算机、桌上型计算机、掌上型计算机（如平板电脑、智能手机等）等电子设备与智能穿戴设备（如智能手环、智能手表、智能眼镜、智能戒指等）等涉及安装运营商提供的定制应用的场景。
基于上述描述的现有基于定制OTA包的定制应用的下载方案存在的技术问题，提出了本申请实施例提供的定制应用的下载系统。
为了更好的描述本申请实施例提供的定制应用的下载系统，以端侧设备为手机，分别结合图3和图4对手机的硬件结构和软件结构进行描述。
参见图3，图3为本申请实施例示出的一种手机的结构示意图。图3虽然以手机为例说明端侧电子设备的结构，但本领域技术人员明了，图3中的手机的结构也适用于智能手表、平板电脑等电子设备。如图3所示，手机100可以包括处理器110，外部存储器接口120，内部存储器121，USB接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。
可以理解的是，本申请实施例示意的结构并不构成对手机100的具体限定。在本申请另一些实施例中，手机100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processingunit，GPU），图像信号处理器（image signal processor，ISP），控制器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等，可支持USB1.0、USB2.0、USB3.0和USB4.0或者更高标准USB规范在内的各种USB规范。示例性的，USB接口130可以包括一个或多个USB接口。
此外，处理器110还用于从本申请实施例提供的定制应用的下载系统中涉及的云端服务器获取数据，如从查询服务器获取定制应用列表清单、定制OTA参数包（运营商指定的一些资源参数包）和定制布局文件等，并根据获取到的定制应用列表清单在显示屏194中显示针对当前用户和手机可供选择的运营商应用程序。
此外，处理器110还用于从本申请实施例提供的定制应用的下载系统中涉及的独立应用存储服务器中获取储满足运营商定制需求的定制应用的源文件（如APK），并通过对定制应用的源文件进行解析安装。
可理解的，在实际的应用场景中，专门存储查上述所说的查询信息的查询服务器和专门存储定制应用的源文件的独立应用存储服务器，可以是支持OTA技术的OTA服务器。
此外，可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对手机100的结构限定。在本申请另一些实施例中，手机100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
充电管理模块140用于从充电器接收充电输入。电源管理模块141用于连接电池142，充电管理模块140与处理器110。手机100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。手机100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
移动通信模块150可以提供应用在手机100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器（lownoise amplifier，LNA）等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。
无线通信模块160可以提供应用在手机100上的包括无线局域网（wireless localarea networks，WLAN）（如无线保真（wireless fidelity，Wi-Fi）网络），蓝牙（bluetooth，BT），全球导航卫星系统（global navigation satellite system，GNSS），调频（frequencymodulation，FM），近距离无线通信技术（near field communication，NFC），红外技术（infrared，IR）等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。
在一些实施例中，手机100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得手机100可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统（global system for mobile communications，GSM），通用分组无线服务（general packet radio service，GPRS），码分多址接入（code divisionmultiple access，CDMA），宽带码分多址（wideband code division multiple access，WCDMA），时分码分多址（time-division code division multiple access，TD-SCDMA），长期演进（long term evolution，LTE），BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统（global positioning system，GPS），全球导航卫星系统（globalnavigation satellite system，GLONASS），北斗卫星导航系统（beidou navigationsatellite system，BDS），准天顶卫星系统（quasi-zenith satellite system，QZSS）和/或星基增强系统（satellite based augmentation systems，SBAS）。
手机100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。
外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展手机100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
手机100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。
参见图4，图4为本申请实施例的手机100的软件结构框图。分层架构将软件分成若干层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为五层，从上至下分别为应用程序层，系统框架层，系统库与运行时层（图4中将运行时层“安卓运行时”合在了系统库中）和内核层。
应用程序层可以包括相机，图库，日历，运动健康，WLAN，音乐，视频等应用程序。需要说明的是，图4中示出的应用程序层所包括的应用程序仅为示例性说明，本申请对此不作限定。可以理解的是，应用程序层包括的应用并不构成对手机100的具体限定。在本申请另一些实施例中，相较于图4所示应用程序层包含的应用，手机100可包括更多或更少的应用，手机100也可包括完全不同的应用。
系统框架层为应用程序层的应用程序提供应用编程接口（ApplicationProgramming Interface，API）和编程框架，包括各种组件和服务来支持开发者的安卓开发。系统框架层包括一些预先定义的函数。如图4所示，系统框架层可包括视图系统、窗口管理器、资源管理器、内容提供器等。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可包括视频，图像，音频等。
系统库与运行时层包括系统库和安卓运行时（Android Runtime）。系统库可以包括多个功能模块。例如：浏览器内核，3D图形库（例如：OpenGL ES），字体库等。浏览器内核负责对网页语法的解释（如标准通用标记语言下的一个应用HTML、JavaScript）并渲染（显示）网页。3D图形库用于实现三维图形绘图，图像渲染，合成和图层处理等。字体库用于实现不同字体的输入。安卓运行时包括核心库和虚拟机。安卓运行时负责安卓系统的调度和管理。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
可以理解的是，图4示出的系统框架层、系统库与运行时层包含的部件，并不构成对手机100的具体限定。在本申请另一些实施例中，手机100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。
内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。
为解决现有基于定制OTA包的定制应用下载方案存在的会导致维护难度大，更新耗时长，并且用户体验欠佳的问题，本申请实施例提供的定制应用的下载方案中将每一个定制应用的APK单独进行存储，将定制应用的描述信息及装机/更新所需的参数资源单独存储于另一服务器。如图5为示例性示出的定制应用的下载方法涉及到系统架构示意图，参照图5可知实现定制应用的下载方法的系统包括：提供针对产品（如手机）的定制应用清单等信息的终端厂商服务器、专门存储针对产品（如手机）的定制应用清单的查询服务器、专门存储运营商发布的不同定制应用的APK（定制应用的源文件）的独立应用存储服务器，以及终端厂商根据定制需求生产的电子设备（如手机）。
示例性的，关于存储定制应用的APK的独立应用存储服务器的数量，在实际的应用场景中，可以是一个或多个，图5示出了3个不同的独立应用存储服务器，分别为Server1、Server2和Server3。
此外，在实际的应用场景中，独立应用存储服务器可以是同一厂商提供的不同服务器，也可以是不同厂商提供的。比如，在一个例子中，Server1可以是由运营商1提供的专门存储运营商1发布的各种定制应用的APK的服务器，Server2可以是由运营商2提供的专门存储运营商2发布的各种定制应用的APK的服务器，Server3可以是由运营商3提供的专门存储运营商3发布的各种定制应用的APK的服务器。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，在实际的应用场景中，独立应用存储服务器可以根据存储的定制应用的类型来进行划分。比如，在一个例子中，Server1可以是用来存储各种聊天应用的服务器，Server2可以是用来存储各种影音应用（视频播放应用、音乐播放应用）的服务器，Server3可以是用来存储各种美食应用的服务器。
此外，可理解的，由于在实际的应用场景中各种定制应用的种类、数量越来越多，在保证实现成本，同时便于维护和管理的情况下，可以将多个运营商均需要的定制应用单独存储在一个独立应用存储服务，即作为通用应用的存储服务器，将其他定制应用以类型和/或运营商作为分类标准，在另一独立应用存储服务器中进行存储区域的划分，并分别存储。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，需要说明的是，图5中针对产品的定制应用清单，在实际的应用场景中，具体是由提供产品（如手机）的厂商，即终端厂商服务器，根据运营商提供的定制需求，结合发布的定制应用的描述信息生成的。
示例性的，定制应用清单可以根据产品的型号来区分。如不同型号的手机分别对应不同的定制应用清单。
此外，在一个例子中，定制应用清单中还可以记录不同型号的手机后期投入的市场类型，以及用户接入的运营商类型等。
由此，便可以实现对用户群体的区分，从而根据需求为不同的用户群体推送不同的定制应用，使得定制应用的推送、下载更加人性化。
此外，为了保证本实施例提供的定制应用的推送、下载能够因产品而异，手机的生产厂商在生产手机的时候，需要预先写入手机的用户类型。
示例性的，在实际的应用场景中，上述所说的用户类型包括但不限于手机型号、实用的市场（如中国市场、海外市场）、所属运营商（如运营商1）等信息。
进一步地，在实际的应用场景中，当手机写入上述用户类型上市后，用户购买手机后首次开机时（触发开机向导），手机便会向查询服务器发起查询待下载应用的请求（可以成为预装请求），同时该请求中会携带上市用户类型。
相应地，当查询服务器接收到任一手机发起的携带了上市用户类型信息的查询请求后，便会根据用户类型与存储针对不同类型的产品，或者不同市场，或者不同运营商的定制应用清单确定适合当前发起请求的手机的定制应用清单列表，然后将确定的定制应用清单列表推送至端侧的手机。
此外，在本实施例中，推送给手机的定制应用清单列表中具体包括了当前手机可以下载的各种定制应用的描述信息，如应用图标、名称、大小等。
相应地，当手机接收到查询服务器推送的待下载的定制应用清单列表后，用户便可以根据定制应用清单列表自主选择需要下载的应用，然后触发手机向存储选中的定制应用的独立应用存储服务器获取需要下载的定制应用的APK。
此外，存储针对产品的定制应用清单的查询服务器与存储定制应用的APK的各个独立应用存储服务器之间预先建立有网络连接，从而查询服务器可以周期性的，比如一周向各个独立应用存储服务器发起一次获取新增APK对应的定制应用的描述信息，或者更新版本的定制应用的描述信息，并根据获取到的信息对定制应用清单进行更新。
此外，在另一个例子中，专门存储定制应用的APK的各个独立应用存储服务器，也可以在存储的APK的版本发生变化，或者新增APK，或者删除已有APK时，主动向查询服务器推送变更信息，以便查询服务器能够对定制应用清单进行实时、准确的更新，从而使得后续跟进定制应用清单能够为手机进行精准的应用清单列表的推送。
此外，在另一个例子中，提供定制应用清单的手机生产厂商，还可以预先配置能够与定制应用匹配的定制布局文件，并将定制布局文件单独存储在查询服务器中。
此外，在另一个例子中，终端厂商服务器也可以根据运营商的定制需求生产定制布局文件。
进一步地，为了在向端侧需要安装定制应用的电子设备，如手机推送用于显示定制应用的名称、图标、大小等描述信息的应用清单列表时，能够将匹配的定制布局文件一同推送给手机，可以预先将定制布局文件与定制应用清单建立映射关系，从而在推送应用列表清单时，能够将有映射关系的定制布局文件也推送给手机。
比如，先由终端厂商服务器根据运营商提供的定制需求，生成所述电子设备安装所述定制应用时采用的定制布局文件；然后由终端厂商服务器建立所述定制布局文件与所述定制应用清单的之间的第一映射关系，得到映射关系表；最后由终端厂商服务器将所述定制布局文件和所述映射关系表发送至所述查询服务器。
相应地，查询服务器在接收到终端厂商服务器发送的定制布局文件和映射关系表后，根据所述映射关系表中记录的所述第一映射关系，将所述定制布局文件与所述定制应用清单进行绑定，并在向所述电子设备推送所述目标定制应用清单时，向所述电子设备推送绑定的所述定制布局文件。
此外，在另一个例子中，也可以将定制布局文件和应用清单列表合在一个文件中，从而在向手机推送应用清单列表时，能够将需要展示的定制应用的描述信息和定制布局文件一同推送给手机。
此外，在另一个例子中，为了能够使得本申请实施例提的定制应用的下载方法可以适用于运营商，在查询服务器中，还可以预置安装运营商指定的定制应用所需的各种定制OTA参数包，即定制参数资源。
示例性的，定制参数资源可以先由终端厂商服务器根据运营商提供的定制需求，确定需要配置到所述电子设备中的定制参数资源；然后由终端厂商服务器建立所述定制参数资源与所述定制应用清单之间的第二映射关系，并将所述第二应关系添加到所述映射关系表；最后由终端厂商服务器将所述定制参数资源和所述映射关系表发送至所述查询服务器。
相应地，查询服务器在接收到终端厂商服务器发送所述定制参数资源和所述映射关系表后，根据所述映射关系表中记录的所述第二映射关系，将所述定制参数资源与所述定制应用清单进行绑定，并在向所述电子设备推送所述目标定制应用清单时，向所述电子设备推送绑定的所述定制参数资源。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
进一步地，在实际的应用场景中，如果是针对运营商指定的定制应用的下载，则存储在查询服务器中的应用清单列表、定制布局文件和匹配的定制OTA参数包，可以打包在一起，作为一个定制OTA包进行存储，以更好的适用于运营商的定制应用场景。
具体的，对于运营商的定制应用场景，查询服务器向手机推送的信息具体可以是上述所说的定制OTA包，手机在接收到定制OTA包后，通过解析出来，得到应用清单列表、定制布局文件和匹配的定制OTA参数包。
此外，可理解的，对于非运营商的定制应用场景，如通用渠道内对某些应用的下载，同样可以适用于本申请实施例提供的定制应用的下载方法，只要将应用的描述信息，如名称、大小、图标等单独存储在查询服务器，将应用的APK单独存储在独立应用存储服务器即可。
此外，为了更好的理解基于本申请实施例提供的定制应用的下载系统，向运营商或者其他渠道的客户群体定制的手机推送需要预装的定制应用时，能够因向每个手机选择性的推送特定的定制影响，以下结合图6示出的场景示意图进行说明。
参见图6，假设运营商1的定制需求是希望其定制的手机能够从APK1和APK2_V1中选择定制应用下载，故而运营商1会提供APK1和APK2_V1存储到独立应用存储服务器。
相应地，假设运营商2的定制需求是希望其定制的手机能够从APK1、APK2_V2和APK3中选择定制应用下载，故而运营商2会提供APK1、APK2_V2和APK3存储到独立应用存储服务器。
相应地，假设运营商3的定制需求是希望其定制的手机能够从APK2_V2和APK3中选择定制应用下载，故而运营商3会提供APK2_V2和APK3存储到独立应用存储服务器。
基于上述前提，当运营商1定制的手机群体中的手机满足预装条件时，可以根据用户的选择在手机A1中安装APK2_V1，在手机C1中安装APK1，而手机B1则暂时不安装APK1、APK2_V1。
相应地，当运营商2定制的手机群体中的手机满足预装条件时，可以根据用户的选择在手机A2中安装APK1，在手机B2中安装APK3，在手机C2中安装APK2_V2。
相应地，当运营商3定制的手机群体中的手机满足预装条件时，可以根据用户的选择在手机A3中安装APK2_V2，在手机B3中安装APK2_V2和APK3，在手机C3中安装APK3。
由此，实现了定制应用的下载能够因人而异，提升了用户体验。
可理解的，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，可理解的，不论是针对运营商的应用下载场景，还是非运营商的应用下载场景，获取需要的（定制）应用的方式均相同，为了更好的说明本实施例提供给的定制应用的下载方法，以下以运营商的定制应用下载，即需要涉及定制OTA参数包这一特殊应用场景为例，并以位于云端的专门存储定制应用的APK的独立应用存储服务器为一个，结合图7进行说明。
参见图7，本实施例提供的定制应用的下载方法适用于的系统具体分为三个子系统。这三个子系统分别为云端子系统、平台侧子系统和端侧子系统。
需要说明的，上述所说的云端子系统，具体包括用于存储定制应用的APK的独立应用存储服务器和存储不同版本的定制OTA包的查询服务器。
进一步地，在实际的应用场景中，云端子系统还可以包括图7中示出的用于存储渠道标识的渠道标识服务器，以便后期推送给端侧的手机需要下载的应用清单列表时，还可以根据渠道标识进行区分。
在一个例子中，关于存储在渠道标识服务器的渠道标识，可以由生产端侧的手机等需要安装定制应用的电子设备的厂商提供。
此外，关于独立应用存储服务器存储定制应用的APK的过程，以下结合图7和图8进行说明。
如图8所示，存储在独立应用存储服务器的定制应用的APK，具体是定制应用的源文件，而定制应用的源文件是根据运营商的定制需求确定的定制内容中的一项，即存储在独立应用存储服务器中的定制应用的APK是由对应的运营商提供的。
定制应用的APK在发布到独立应用存储服务器时，如图7所示，会在独立应用存储服务器内发起注册应用的操作，并且在审批通过后，执行发布上网的操作将需要发布的定制应用的APK发布到发布应用池中进行存储，以便后续接收到端侧的手机发起的下载某一定制应用的请求时，能够从发布应用池中查找到需要下载的定制应用对应的APK推送给手机。
此外，为了便于后续维护，可以在独立应用存储服务器中增加下载打点的功能，即端侧的电子设备每次从独立应用存储服务器中的发布应用池中下载定制应用的APK时，便执行下载打点功能，以记录哪一电子设备（根据电子设备的标示信息，如出厂号等）在哪一时刻下载了哪个定制应用的哪个版本，以及是否下载成功等日志信息，以便后续维护更新。
关于在独立应用存储服务器中实现定制应用的发布的具体流程，详见图9。如图9所示，具体包括：
步骤101，上传APK。
可理解的，本实施例需要发布到独立应用存储服务器中发布应用池中的APK即为根据运营商定制需求定制的定制应用的APK，故而此处上传的APK即为定制应用的APK。
步骤102，测试APK。
可理解的，为了保证后期从独立应用存储服务器推送给端侧的电子设备的定制应用APK为正常可用的，故而在发布APK时需要先对APK进行测试，确保当前版本的APK是否可用，且实现了当前版本所要实现的功能。
步骤103，上传测试报告。
具体的，在完成对APK的测试操作后，会生成对应的测试报告，测试报告会标明当前需要发布到发布应用池的APK是否正常。
相应地，若测试报告标明该APK正常，则确定该APK通过测试，此处可以进入发布流程；反之，则重新上传APK，直到上传的APK测试通过，才进入发布流程。
步骤104，发布流程。
具体的，此处所说的发布流程，具体是指将测试通过的APK发布到发布应用池中，关于发布流程的具体实现过程，本实施例对此不做说明。
步骤105，发布完成，即应用发布到了发布应用池中。
示例性的，在实际的应用场景中，假设初次注册应用操作时，提交的版本为A版本，此处除了需要在独立应用存储服务器中发布A版本的定制应用的APK，平台侧还需将对应的定制OTA包发布到查询服务器中，若后续再次触发的注册应用的操作是上传定制应用的B版本（非谷歌商店Play上架版本），这种情况下，本实施例提供的方案仅需发布B版本的定制应用的APK到独立应用存储服务器的发布应用池即可，平台侧无需对定制OTA包进行更新，也无需向查询服务器重新发送定制OTA包。
此外，可理解的，在实际的应用场景中，定制应用的APK也可以是由其他平台，或者生产手机的平台根据运营商的定制需求自行开发的。
需要说明的，在注册应用时，会填写需要注册的应用的相关信息，比如应用的基本信息（appInfo）和公共信息（commonInfo）。
进一步地，在实际的应用场景中，在注册应用时，填写的需要注册的应用的相关信息，还包括目标消费者信息、适用范围信息等，此处不再一一列举，本实施例对此不做限制。
示例性的，上述所说的应用的基本信息，包括但不限于：应用ID（appID）、应用名称（appName）、模块结构的包名字（packageName）、选择规则（selectRule）、源文件类型（APKType）、源文件链接（APKLink）、源服务器（OriginServer）。
示例性的，上述所说的公共信息，包括但不限于市场类型（marketType）。
基于此，在对填写了上述相关信息的注册应用的操作审批通过，执行发布上网的操作时，独立应用存储服务器会将上述用来描述应用的相关信息同步到平台侧的公共信息构建模块中的应用信息池中，以便公共信息构建模块根据应用信息池中存储的各个定制应用的相关信息，配置定制应用清单。
此外，本实施例用独立的独立应用存储服务器按市场维度灵活发布和管理定制应用的APK，当运营商的定制需求发生变化，或者定制应用的版本发生版本更新时，只需根据新的应用场景，更新独立应用存储服务器中已有APK的版本，或者删除APK，或者增加APK即可。
此外，上述所说的平台侧子系统在本实施例中具体是指生产端侧的手机等电子设备的厂商提供的与云端子系统和端侧子系统进行交互的平台，即终端厂商服务器。
示例性的，平台侧子系统可以包括图7所示的公共信息构建模块、交付模块、版本管理模块和发布模块。
可理解的，本申请实施例中平台侧子系统中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本申请的创新部分，本实施例中并没有将与解决本申请所提出的技术问题关系不太密切的单元引入，但这并不表明本实施例中不存在其它的单元。
此外，参见图7可知，运营商定制内容包括定制OTA参数包，即参数资源，还有定制应用清单，并且为了实现任一定制应用的APK的单独下载，而不是图1所示的现有基于定制OTA包的定制应用的下载方案中，必须将运营商提供的所有定制应用的APK、参数资源全部进行下载，本申请实施例提供的定制应用的下载方案中，平台侧子系统的公共信息构建模块，通过从应用信息池中取出关于定制应用的相关信息来配置定制应用清单，基于预置的参数资源配置定制OTA参数包，最终根据配的定制应用清单和定制OTA参数包创建不同版本的定制OTA包，并将不同版本的定制OTA包传输至交付模块，由交付模块生成不同版本的定制OTA包，同时将生成的不同版本的定制OTA包传输至版本管理模块和发布模块，版本管理模块确定交付模块生成的不同版本的定制OTA包中是否存在运营商所需的定制OTA参数包，如果没有就重新配置定制OTA参数包，即重新配置缺失的参数资源，同时版本管理模块检测交付模块生成的不同版本的定制OTA包中定制应用清单中的哪个定制应用需要设置特殊的权限信息，比如定制应用清单中的“浏览器”应用用户必须下载，并且不可删除，版本管理模块在完成上述操作后，将增加的定制OTA参数包和设置了特定权限后的定制应用清单发送至发布模块，发布模块对来自交付模块的不同版本的定制OTA包和来自版本管理模块的数据进行汇总，最终得到仅包括关于定制应用的相关信息和参数资源，不包括定制应用的APK的定制OTA包（本申请实施例提供的定制应用的下载方法中后续涉及的定制OTA包，均不包括定制应用的源文件），并将得到相应版本的定制OTA包上传至云端子系统的查询服务器进行存储。
此外，在实际的应用场景中，在平台侧子系统中的公共信息构建模块中还可以设置度量统计程序，以统计哪些应用经常被运营商指定为定制应用，从而便于后续推广。
为了更好的理解上述过程，以图9示出的平台侧子系统中公共信息构建模块和发布模块交互实现不同版本的定制OTA包的发布为例，对平台侧子系统生成定制OTA包，并发布到云端查询服务器查询服务器的过程进行说明。参见图9，具体过程如下：
公共信息构建模块根据应用基本信息和预置的运营商需求配置定制应用清单和布局文件，同时根据运营商需求配置参数、资源等信息，然后根据配置的定制应用清单、定制布局文件和参数及资源生成定制OTA包，并将生成的定制OTA包上传到发布模块，由发布模块将定制OTA包发布到查询服务器。
示例性的，图9给出了一种定制OTA包的具体命名格式（通过命名提示定制OTA包的版本），以及查询服务器存储的定制OTA包相关信息的具体形式。如图9所示，首次生成的定制OTA包的具体命名格式为“ELZ-N49-COTA-Nornal6.0.0.1(gbrc150R1)”，在不同版本的定制OTA包上做出更新的定制OTA更新包1的命名为“ELZ-N49-COTA-Nornal6.0.0.1(gbrc150R2)”，在定制OTA更新包1版本上做出更新的定制OTA更新包2的命名为“ELZ-N49-COTA-Nornal6.0.0.2(gbrc150R2)”，在定制OTA更新包2版本上做出更新的定制OTA更新包3的命名为“ELZ-N49-COTA-Nornal6.0.0.3(gbrc150R3)”。
可理解的，上述给出的仅为一种具体的定制OTA包的命名格式，对本申请实施例提供的技术方案并不构成任何限定。
此外，从图9可以看出，发布到查询服务器的初始版本的定制OTA包具体包括了更新日志文件（Changelog.xml）、更新的定制OTA包压缩文件（Update_cota.zip）、文件列表文件（Filelist.xml）、R1版本的定制应当配置清单文件（定制应用配置清单_R1.xml）和R1版本的定制布局文件（布局R1.xml）。
可理解的，查询服务器中存储的各文件的命名，仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
通过上述描述可知，定制OTA更新包是在定制OTA包的版本上更新的，此次更新仅更新了定制应用配置清单文件（定制应用配置清单_R1.xml更新为了定制应用配置清单_R2.xml）和定制布局文件（布局R1.xml更新为了布局R2.xml），其他文件不变，即Changelog.xml、Update_cota.zip和Filelist.xml可以复用定制OTA包中的，无需进行修改。
相应地，从图9可以看出，在定制OTA更新包1版本的基础上更新得到的定制OTA更新包2具体是更新了Changelog.xml、Update_cota.zip和Filelist.xml，而定制应用配置清单_R2.xml和布局R2.xml可以直接复用定制OTA更新包1中的，无需进行修改。
相应地，在定制OTA更新包2版本的基础上更新得到的定制OTA更新包3对需要存储到查询服务器的上述五个文件均做了修改，故而无法复用定制OTA更新包2中的任一文件，全部都需要进行更新。
此外，为了实现不同用户群体中定制应用的布局也可以因而应用而已、因人而异，在创建不同版本的定制OTA包时，还可以添加预置的定制文件布局。即，存储在查询服务器中的定制OTA包中，包括了图8所示的定制OTA参数包、定制应用清单和定制布局文件。
需要说明的，本实施例中所说的定制OTA参数包的作用具体是实现向端侧的电子设备推送定制参数、图标logo、铃声、主题等参数资源，其演进形式为单线全量包。
此外，本实施例中所说的定制应用清单的包括但不限于上述列举的与定制应用相关的信息，其演进形式为分批次多线演进，如在定制应用的APK范围发生变更（如增删）时，需要增发定制应用的清单批次。
此外，本实施例中所说的定制布局文件的作用具体是实现增量定制布局，其演进形式为与定制应用清单相同，同样为分批次多线演进。
此外，在实际的应用场景中，可以设置定制布局文件随定制应用清单的变更而同步变更，从而保证定制布局文件能够适配不同的定制应用清单。
此外，上述所说的端侧子系统具体包括需要安装定制应用的电子设备，如手机。
示例性的，以端侧子系统的电子设备为手机为例，在检测到手机满足预设条件时，手机向查询服务器上报预先置入手机的用户类型信息（包括但不限于手机型号、实用的市场（如中国市场、海外市场）、所属运营商（如运营商1）等信息），便会匹配出适合当前发起请求的手机的版本的定制OTA包，同时如果云端子系统存在存储渠道标识的渠道标识服务器，从渠道标识服务器中获取当前发起请求的手机对应的渠道标识。
示例性的，手机根据获取到的包含了定制布局文件和定制应用清单的定制OTA包和标识手机所属的渠道标识，在手机的显示界面做出不同版本的定制OTA包通知，比如通知进行开机启动，或者应用更新。
示例性的，为了提升用户体验，可以通过图标的形式在手机的安卓桌面启动器（Launcher）中显示对应的图标。
为了更好的理解本实施例提供的定制应用的下载方法中，在端侧的电子设备，如手机，根据检测结果做出提醒的流程，以下结合图10a~图12b进行说明。
参见图10a，图10a给出了端侧的手机未安装过定制应用时应用版本检测提醒的实现流程。如图10a，具体包括：
步骤201，触发开机向导/软件更新客户端（OTA Update Client，OUC）请求。
具体的，此步骤是由端侧的手机触发的。
示例性的，在实际的应用场景中开机向导/OUC的触发操作，可以是检测到用户触发了手机的显示界面中的预设的功能按钮，也可以是检测到首次开机后，自动触发的，本实施例对此不做限制。
步骤202，上报检测信息。
具体的，从端侧的手机上报到提供查询服务的查询服务器的检测信息包括默认的版本号和批次号。
此外，在一个例子中，上报的检测信息，还包括但不限于在手机的生产线上预先置入手机的手机型号、后期投入的市场，以及开机后检测到的手机插入的SIM卡所属的运营商等能标识使用手机的用户群体的信息。
步骤203，检测定制OTA参数以及定制应用清单列表。
步骤204，匹配定制OTA参数以及定制应用。
具体的说，查询服务器根据手机上报的上述检测信息，对本地存储的参数资源、定制应用清单、定制布局等文件进行检测，进而匹配出与上报检测信息的手机匹配的定制OTA包参数以及定制应用。
步骤205，请求定制应用的描述信息。
具体的，查询服务器在匹配出与上报检测信息的手机匹配的定制OTA包参数以及定制应用后，便会向专门存储定制应用的APK的独立应用存储服务器请求匹配出的定制应用的描述信息。
示例性的，在实际的应用场景中，查询服务器向独立应用存储服务器请求的定制应用的描述信息，包括但不限于独立应用存储服务器存储的匹配出的定制应用最新APK版本信息、大小，以及图标。
步骤206，下发定制应用的描述信息。
具体的，独立应用存储服务器从本地查找到查询服务器请求的定制应用的描述信息后，便会将查找出的描述信息下发给查询服务器，供查询服务器进行后续处理。
示例性的，查询服务器向独立应用存储服务器请求的仅仅是匹配出的定制应用的描述信息，而非定制应用的APK 。
相应地，独立应用存储服务器下发给查询服务器的也仅仅是定制应用最新的描述信息，而非定制应用的APK。
步骤207，生成需要推送的应用列表。
具体的，查询服务器根据独立应用存储服务器下发的定制应用的描述信息，生成后续需要推送给手机的应用列表，供使用手机的用户查看该手机可以下载安装哪些运营商应用。
步骤208，下发检测结果。
可理解的，在实际的应用场景中，检测结果不外乎确定有可以安装的定制应用，或有新版本的应用发布，或者没有检测到适合在当前手机安装的定制应用。故而，下发查询服务器下发的检测结果，实质就是告知手机当前是否有适合当前手机安装的定制应用。
步骤209，根据检测结果做出提醒。
参见图12a和图12b，图12a是示例性示出的在锁屏状态时检测到定制应用更新版本后显示的通知界面图，图12b是示例性示出的在主界面时检测到定制应用更新版本后显示的通知界面图。
示例性的，图12a示出的通知界面图中，通知框中显示了要提示的内容“有新版本发布”，以及新版本的来源描述“运营商应用程序可用于您的设备”，以及供用户操作的功能按钮“更新”和“稍后”。
示例性的，如果用户点击了“更新”按钮，则手机会从专门存储要更新的定制应用的APK的服务器，如上文所说的独立应用存储服务器，请求下载发布的新版本；如果用户点击了“稍后”按钮，在实际的应用场景中，可以直接退出该通知框，也可以弹出供用户选中稍后处理的时间等，此处不再一一列举，本实施例对此也不做赘述。
示例性的，图12b示出的通知界面中，主界面中显示了手机已安装的应用，如图12b中的“时钟”、“日历”、“图库”、“备忘录”、“文件管理”、“电子邮件”、“音乐”、“计算机”、“相机”、“通讯录”、“电话”、“信息”，叠加在主界面上的通知框中显示了运营商设置，此时有“运营商应用程序可用于您的设备”，并提供了供用户操作的功能按钮“下载并安装”、“描述信息”和“稍后”。
示例性的，如果用户点击了“下载并安装”按钮，则手机会从专门存储需要下载并安装的定制应用的APK的服务器，如上文所说的独立应用存储服务器，请求下载并安装定制应用；如果用户点击了“描述信息”的按钮，则可以显示可下载并安装的定制应用的描述信息，如上文所说的定制应用清单；如果用户点击了“稍后”按钮，在实际的应用场景中，可以直接退出该通知框，也可以弹出供用户选中稍后处理的时间等，此处不再一一列举，本实施例对此也不做赘述。
此外，在实际的应用场景中，如果有匹配的定制OTA参数包，则复用定制OTA包提醒，通过更新日志（Changelog）的方式来查看确定的应用列表。
相应地，如果没有匹配的定制OTA参数包，则采用安卓系统提供的通知方式进行提醒。
进一步地，如果预设周期，如7后检测到有匹配的HOTA参数包，则复用HOTA提醒。
此外，在实际的应用场景中，还可以预设提醒周期，如在有匹配的定制OTA参数包时，每天1次弹框提醒。
此外，在另一个例子中，还可以设置提醒过程逐渐弱化，即提醒的间隔天数逐渐增加，比如前4天，每天弹框提醒一次，如果用户不作为（不更新/下载），或者直接选择忽略，则之后间隔3天弹框提醒一次，下次再间隔5天弹框提醒一次，最后一次则间隔7天弹框提醒一次。
此外，在另一个例子中，也可以每间隔一天弹框提醒一次。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，为避免新发布的手机对应的检测信息还未导入查询服务器，导致手机上报检测信息后，无法查找到对应的定制OTA包，进而导致后续的检测流程无法正常推进，图10b给出了端侧的手机未安装过定制应用时应用版本检测提醒又一的实现流程。如图10b，具体包括：
步骤301，触发开机向导/OUC。
步骤302，上报检测信息。
不难发现，图10b给出的手机未安装过定制应用时应用版本检测提醒的实现流程中步骤301、步骤302，分别与图10a给出的手机未安装过定制应用时应用版本检测提醒的实现流程中步骤201、步骤202相同，关于步骤301和步骤302的具体实现，此处不再赘述。
步骤303，本地是否存储了定制OTA包。
需要说明的，在实际的应用场景中，可能存在新发布的手机对应的检测信息还未导入查询服务器，比如查询服务器中仅包括手机型号A的检测信息对应的定制OTA包、手机信号B的检测信息对应的定制OTA包。当新发布一款型号为C的手机时，如果型号为C的手机触发了开机向导/OUC，并向查询服务器上报了检测信息，此时由于查询服务器还未导入手机型号C的检测信息对应的定制OTA包，为了不影响后续流程的执行，查询服务器会向提供定制OTA包的平台侧请求定制OTA包。
也就是说，在查询服务器本地没有存储当前上报检测信息的手机对应的定制OTA包时，查询服务器会向平台侧发起请求定制OTA包的请求，即执行步骤304；否则，直接根据本地存储的当前上报检测信息的手机对应的定制OTA包，执行步骤306的操作。
步骤304，请求定制OTA包。
示例性的，为了使平台侧获知查询服务器请求的是哪个定制OTA包，查询服务器在向平台侧发起请求定制OTA包的请求时，可以携带当前上报检测信息的手机上报的检测信息，以便平台侧能够准确定位匹配的定制OTA包。
步骤305，下发定制OTA包。
示例性的，如果在实际的应用中间中，存在请求多个手机对应的定制OTA包，平台侧在下发定制OTA包时，可以建立每一手机与匹配的定制OTA包之间的对应关系，然后将多个定制OTA包，以及建立的对应关系下发至查询服务器，以便查询服务器根据对应关系，确定每一个类手机对应的定制OTA包。
步骤306，检测定制OTA包参数以及定制应用清单列表。
步骤307，匹配定制OTA包参数以及定制应用。
不难发现，图10b给出的手机未安装过定制应用时应用版本检测提醒的实现流程中步骤306、步骤307，分别与图10a给出的手机未安装过定制应用时应用版本检测提醒的实现流程中步骤203、步骤204相同，关于步骤306和步骤307的具体实现，此处不再赘述。
步骤308，本地是否存储了定制应用的描述信息。
需要说明的是，查询服务器与独立应用存储服务器之间会建立网络连接进行通信，具体可以是查询服务器周期性的，如一周，主动从独立应用存储服务器获取一次独立应用存储服务器中存储的定制应用的APK对应的描述信息；还可以是独立应用存储服务器在检测到存储的定制应用的APK发生版本信息的变化，或者新增一个定制应用的APK，或者删除已有定制应的APK时，主动向查询服务器下发变更信息。故而，查询服务器在匹配出定制OTA包参数以及定制应用后，可以先检测本地是否存储了匹配出的定制应用的描述信息。
相应地，如果存在匹配出的定制应用的描述信息则直接执行步骤311的操作；否则，向独立应用存储服务器请求匹配出的定制应用的描述信息。
由此，通过这种机制，既可以保证整个过程的响应速度，又可以保证能够准确的确定检测结果。
步骤309，请求定制应用的描述信息。
步骤310，下发定制应用的描述信息。
步骤311，生成需要推送的应用列表。
步骤312，下发检测结果。
步骤313，根据检测结果做出提醒。
不难发现，图10b给出的手机未安装过定制应用时应用版本检测提醒的实现流程中步骤309至步骤313分别与图10a给出的手机未安装过定制应用时应用版本检测提醒的实现流程中步骤205至步骤209相同，关于步骤3109至步骤313的具体实现，此处不再赘述。
参见图11a，图11a给出了端侧的手机安装过定制应用时应用版本检测提醒的实现流程。如图11a，具体包括：
步骤401，触发OUC。
步骤402，上报检测信息。
具体的，在手机安装过定制应用时，当手机触发OUC操作时，上报给查询服务器的检测信息包括但不限于安装过的定制应用所在定制应用清单的批次，以及已安装的定制应用的ID。
步骤403，检测定制OTA包更新参数以及定制应用的更新版本。
步骤404，匹配定制OTA包更新参数以及定制应用的更新版本。
步骤405，请求待更新应用的描述信息。
具体的，查询服务器在向独立应用存储服务器请求待更新应用的描述信息时，需要先检测独立应用存储服务器是否存在手机已安装的定制应用的更新版本。
示例性的，在检测独立应用存储服务器是否存在手机已安装的定制应用的更新版本时，按照定制应用版本的方式实现检测，无需检测整个定制应用清单中的定制应用。
步骤406，下发待更新应用的描述信息。
步骤407，生成需要推送的待更新应用的应用列表。
步骤408，下发检测结果。
步骤409，根据检测结果做出提醒。
示例性的，手机根据检测结果做出的提醒，同样适用于参见图12a和图12b示出的通知界面图。
此外，不难发现，图11a给出的手机安装过定制应用时应用版本检测提醒的实现流程的步骤401至步骤409实质上与图10a给出的手机未安装过定制应用时应用版本检测提醒的实现流程的步骤201至步骤209大致相同，主要区别之处在于，图11a给出的手机安装过定制应用时应用版本检测提醒的实现流程是针对更新版本的，即检测的是定制OTA包更新参数和定制应用的更新版本，匹配的是定制OTA包更新参数和定制应用的更新版本，请求的是匹配出的待更新应用的描述信息，对于相同之处，此处不再赘述。
此外，为避免手机已安装的定制应用下发布的版本对应的定制OTA更新包和定制应用的更新版本的相关描述信息还未导入查询服务器，导致手机上报检测信息后，无法查找到对应的定制OTA更新包，进而导致后续的检测流程无法正常推进，图11b给出了端侧的手机安装过定制应用时应用版本检测提醒又一的实现流程。如图11b，具体包括：
步骤501，触发OUC。
步骤502，上报检测信息。
步骤503，本地是否存储了定制OTA更新包。
需要说明的，在实际的应用场景中，可能存在新发布定制应用版本对应的定制OTA更新包和定制应用的更新版本的相关描述信息还未导入查询服务器，比如查询服务器中仅包括V1版本的定制应用1对应的定制OTA包和版本信息、V2版本的定制应用2对应的定制OTA包和版本信息。当发布了V2版本的定制应用1时，如果手机触发了/OUC，并向查询服务器上报了检测信息，此时由于查询服务器还未导入V2版本的定制应用对应的定制OTA包和版本信息，为了不影响后续流程的执行，查询服务器会向提供定制OTA包的平台侧请求定制OTA更新包。
也就是说，在查询服务器本地没有存储当前上报检测信息的手机对应的定制OTA更新包时，查询服务器会向平台侧发起请求定制OTA更新包的请求，即执行步骤504；否则，直接根据本地存储的当前上报检测信息的手机对应的定制OTA更新包，执行步骤506的操作。
步骤504，请求定制OTA更新包。
示例性的，为了使平台侧获知查询服务器请求的是哪个定制OTA更新包，查询服务器在向平台侧发起请求定制OTA更新包的请求时，可以携带当前上报检测信息的手机上报的检测信息，以便平台侧能够准确定位匹配的定制OTA更新包。
步骤505，下发定制OTA更新包。
示例性的，如果在实际的应用中间中，存在请求多个已安装定制应用对应的定制OTA更新包，平台侧在下发定制OTA包时，可以建立每一定制应用与匹配的定制OTA更新包之间的对应关系，然后将多个定制OTA更新包，以及建立的对应关系下发至查询服务器，以便查询服务器根据对应关系，确定每一个已安装定制应用对应的定制OTA更新包。
步骤506，检测定制OTA包更新参数以及定制应用的更新版本。
步骤507，匹配定制OTA包更新参数以及定制应用的更新版本。
步骤508，本地是否存储了待更新应用的描述信息。
需要说明的是，查询服务器与独立应用存储服务器之间会建立网络连接进行通信，具体可以是查询服务器周期性的，如一周，主动从独立应用存储服务器获取一次独立应用存储服务器中存储的定制应用的APK对应的描述信息；还可以是独立应用存储服务器在检测到存储的定制应用的APK发生版本信息的变化，或者新增一个定制应用的APK，或者删除已有定制应的APK时，主动向查询服务器下发变更信息。故而，查询服务器在匹配出定制OTA包参数以及定制应用后，可以先检测本地是否存储了匹配出的定制应用的描述信息。
相应地，如果存在匹配出的定制应用的描述信息则直接执行步骤311的操作；否则，向独立应用存储服务器请求匹配出的定制应用的描述信息。
由此，通过这种机制，既可以保证整个过程的响应速度，又可以保证能够准确的确定检测结果。
步骤509，请求待更新应用的描述信息。
步骤510，下发待更新应用的描述信息。
步骤511，生成需要推送的待更新应用的应用列表。
步骤512，下发检测结果。
步骤513，根据检测结果做出提醒。
此外，不难发现，图11b给出的手机安装过定制应用时应用版本检测提醒的实现流程的步骤501至步骤513实质上与图11a给出的手机安装过定制应用时应用版本检测提醒的实现流程的步骤401至步骤409大致相同，主要区别之处在于，图11b给出的手机安装过定制应用时应用版本检测提醒的实现流程中新增了检测本地是否存储了定制OTA更新包，并在确定为存储定制OTA更新包时，向平台侧请求定制OTA更新包，平台侧下发定制OTA更新包，以及检测本地是否存储了待更新应用的描述信息的步骤，对于相同之处，此处不再赘述。
此外，不论是图10a、图10b，还是图11a、图11b给出的关于应用版本检测提醒的实现流程，在用户触发显示的通知界面中获取定制应用的相关按钮时，查询服务器可以将生成的需要推送的应用列表，以适合发起请求的手机的定制OTA包下发给手机，从而手机可以从获取到的适合手机安装的版本的定制OTA包中解析出定制OTA参数包，并将定制OTA参数包交给系统中的安装程序进行安装。
示例性的，手机在检测到用户触发了显示的不同版本的定制OTA包通知中的开机或更新按钮后，便会查询服务器便会向手机推送确定的时候当前手机的应用列表清单信息，并显示应用列表清单中具体的运营商应用程序。
参见图13a，图13a是示例性示出的手机根据查询服务器推送的应用列表清单信息显示可供选择的运营商应用程序的示意图。在图13a中，查询服务器推送给手机的应用列表清单信息中包括了“运动健康”、“视频”和“浏览器”这三个可供当前手机下载的运营商应用程序的信息，如图13a中显示在手机界面中的各应用程序的图标、名称和大小。
此外，在一个例子中，为了实现用户可以自主选择下载显示界面中显示的运营商应用程序，由用户决定是否下载定制应用，或者更新定制应用，手机中显示的运营商应用程序界面中可以如图13b，为显示的运营商应用程序列表中每一个定制应用提供可选框，以便用户选择界面中显示的一个或多个定制应用。示例性的，图13b给出的是用户选中了“浏览器”这一定制应用。
此外，在另一个例子中，为了保证运营商规定的必须在手机安装的定制应用能够全部安装在手机中，可以预先设置此类定制应用默认均为选中状态，用户只需触发运营应用程序界面中设置的，例如图13c中的“下载”按钮，便向存储定制应用的APK的独立应用存储服务器请求“运动健康”、“视频”和“浏览器”这三个定制应用的APK，从而将运营商规定的必须安装的“运动健康”、“视频”和“浏览器”这三个定制应用全部安装到手机。
此外，在另一个例子中，还可以将图13b和图13c示出的两种场景结合到一起，即手机中显示的运营商应用程序的界面中，对于默认必须安装到手机的定制应用，不向用户提供选择框，对于用户可选的定制应用向用户提供选择框，从而用户可以通过一次操作，便将运营商规定的必须安装的定制应用，以及自己需要的定制应用安装到手机中。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，关于本申请实施例提供的定制应用的下载方法中，定制应用的下载及安装的流程如图14所示，具体包括：
步骤601，检测到APK后保存APK信息。
结合图14可知，此步骤具体是由端侧，如手机基于OUC功能实现的，并手机中需要有签名平台（Platform）的系统应用。
可理解的，查询服务器向手机推送的定制应用列表中携带了定制应用对应的APK的描述信息，如定制应用的名称、大小、图标等，当检测到用户触发了对某个定制应用的下载选项后，便会将选择的应用程序对应的上述APK的描述信息进行保存，并授权系统进行下载。
步骤602，授权下载。
步骤603，拼接下载URL以及应用ID串行下载。
示例性的，在实际的应用场景中，授权下载可以是由用户手动授权的。具体的过程如，用户手动授权选中的定制应用下载时，OUC会使用超文本传输协议（HyperTextTransfer Protocol，HTTP）或者超文本传输安全协议（Hyper Text Transfer Protocolover SecureSocket Layer），HTTPS）向专门存储定制应用的APK的独立应用存储服务器发起请求。
此外，在另一种应用场景中，授权下载可以是在检测到满足预设条件，如手机当前接入的网络为无线局域网（Wireless Local Area Network，WLAN）时确定满足自动下载条件，此时OUC便会使用HTTP协议或HTTPS协议自动向独立应用存储服务器发起下载请求。
此外，在实际的应用场景中，为了让用户获知下载状态，可以在手机的主界面中显示如图15a所示的界面，以告知用户选中的定制应用“正在下载”。
进一步地，为了更加清楚明了的显示下载进度，还可以在手机的通知栏，获知当前界面中“正在下载”字体下显示下载进度条。
此外，如果下载选中的定制应用的APK的过程，手机还在从查询服务器下载定制OTA包参数等信息，则可以在通知栏分别显示两种内容的下载进度，也可以将二者进行合并呈现。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
步骤604，下载完成。
需要说明的，在选中的定制应用的APK（源文件）下载完成后，需要检测手机是否满足安装条件，而非立即进行安装，因此下载完成后，需要先将定制应用的APK存储到手机的下载目录中。
步骤605，存储到下载目录。
示例性的，本实施例中下载得到的定制应用的APK存储的下载目录具体为“data/update/OUC/cloudapp”，即后续确定手机满足安装条件后，会从此下载目录下获取定制应用的APK。
应当理解的，上述给出的仅仅为一种具体的存储路径，是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，为了保证这些定制应用的APK的安全性，避免被篡改，导致无法正常使用，可以对存储这些APK的下载目录进行一系列的安全防护措施。
比如，单独新建一个存储区域设置为“data/update/OUC/cloudapp”，并通过安全增强型Linux（Security-Enhanced Linux， SELinux）权限管控，仅PlatformApp（有安卓平台签名的系统应用）有读写权限。
进一步地，还可以设置“data/update/OUC/cloudapp”对普通应用不可见、不可写。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
步骤606，确定满足安装条件。
可理解的，本实施例中所说的满足安装条件，可以是满足用户授权或到达自动安装时间。
比如，如果用户手动授权了定制应用安装，则确定满足安装条件，后续会启动定制应用的静默安装流程。
还比如，对于定制应用的APK原本就是满足自动下载条件进行下载的，如果检测到软件更新的夜间升级模式，或者闲时升级模式开关处于打开状态，则会在夜间，或者手机处于空闲不使用时，自动执行对定制应用的APK的校验和静默安装流程。
还比如，对于下载过程与定制OTA包或HOTA包融合的情况，可以在定制OTA包与HOTA包安装完成后，确定满足对定制应用APK的安装条件。
还比如，如果手机设置了重启安装的功能，则在定制应用APK下载完成后，检测到手机重启，则确定满足安装条件。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
步骤607，对应用清单进行校验。
具体的说，为避免下载的APK实质并非用户选中的定制应用的APK，在进行安装之前，需要先校验一下下载的APK是否与应用清单中的是同一。
示例性的，本实施例给出了一种具体的校验方法，具体是通过对下载目录下存储的定制应用的APK计算SHA256摘要，同时计算检测阶段获取到SHA256值，并将这两个值进行比较。
相应地，如果通过比较，确定二者匹配，则通过校验，执行步骤608中的操作；否则，确定校验失败，并通知用户。
步骤608，校验通过，调用接口通知PMS启动应用安装接口。
具体的，在校验通过后OUC会调用接口通知安装包管理服务（PackageManagerServic，PMS）启动应安装接口，对存储在下载目录中的定制应用的APK进行安装。
步骤609，获取应用源文件。
具体是由PMS从存储下载的定制应用的APK的下载目录中获取存储的APK。
步骤610，安装。
示例性的，在安装过程中，可以在手机的主界面中显示如图15b所示的界面图，以告知用户选中的定制应用“正在安装”中。
步骤611，安装完成。
具体的，PMS启动应用安装接口对定制应用安装完成后，会通知OUC，以便OUC进行后续处理。
示例性的，在安装完成后，手机的主界面便会显示已安装完成的定制应用的图标和名称，如图15c所示显示的是“浏览器”应用已安装完成。
步骤612，删除应用源文件。
可理解的，为了避免对手机的存储空间造成不必要的占用，在定制应用安装完成后，便可以从下载目录中删除已安装的定制应用对应的源文件，即APK，进而释放用户存储空间。
步骤613，提醒用户本次安装结果。
即，告知用户安装成功，或失败等。
由此，实现了存储定制应用的APK的独立应用存储服务器与提供查询功能的查询服务器完全独立，并且端侧的电子设备在获取定制应用时，云端可以根据不同的用户推送特定的定制应用，并可以通过查询服务器与独立应用存储服务器的交互，实现按需、动态的更新以及变更定制应用清单，并向端侧的电子设备推送更新信息，提醒用户是否下载和更新。
此外，通过上述描述可知，本申请实施例提供的定制应用的下载方法中，在查询服务器中还存储了与定制应用对应的定制布局文件。为了更好的理解定制布局文件的下载及生效过程，以下结合图16进行具体描述。如图16，具体包括：
步骤701，请求定制布局。
通过上述描述可知，定制布局文件是存储在查询服务器中，因此OUC具体是想查询服务器发起请求，以从查询服务器获取定制布局文件。
可理解的，在实际的应用场景中，OUC在向查询服务器请求定制布局文件时，需要上报预置在手机中，能够标识手机型号、适用场景、所属运营商，以及需要下载的定制应用等信息，以便查询服务器能够像手机下发时候当前手机的定制布局文件。
此外，在一个例子中，请求定制布局文件的操作，可以是在请求定制应用清单时同时进行的，从而减少了手机向查询服务器的请求次数，尽可能减少了响应等待时间，提升定制应用的整体下载速度，以给用户带来更好的用户体验。
步骤702，返回定制布局的URL。
可理解的，本实施例给出的一种实现方式是，查询服务器在接收到手机发起的定制布局文件的请求后，返回给手机的OUC的是请求的定制布局的的具体URL，这样用户便可以自主决定当前是否要从该URL获取定制布局文件。
比如，在手机当前接入的网络是移动蜂窝网络，或者网络质量较差时，用户可以选择暂时不下载定制布局文件，待手机接入的网络变成无线局域网，或者网络质量变好时，在触发手机根据接收到的URL从查询服务器获取定制布局文件。
此外，在另一种应用场景中，也可以设置查询服务器在接收到手机发起的定制布局文件的请求后，直接将匹配出的定制布局文件下发给手机，从而减少用户操作，以及手机的多次请求。
步骤703，下载布局文件。
示例性的，为了避免重复下载定制布局文件，不必要的占用手机存储空间，可以在执行步骤701或者步骤703之前，先检测一下手机本地是否已经生效过定制布局文件，如果已经生效过，则无需再执行上述操作；或者，检测一下手机本地是否存储了未生效过的定制布局文件，如果存在，也无需再执行上述操作。
步骤704，返回布局文件。
步骤705，保存定制布局文件。
示例性的，本实施例给出了定制布局文件的保存路径，如“/data/update/OUC/cloudapp/cotalayout”，并且同定制应用APK的下载目录类似，存储定制布局文件的目录同样采用SELinux权限管控，并设置仅PlatformApp（有安卓平台签名的系统应用）有读写权限。
可理解的，为了便于对本申请实施例提供的定制应用的下载方案的描述，上述是以安卓系统为例进行具体说明的，故而涉及到的一些功能是与安卓相关的，这仅仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际的应用场景中，本申请实施例提供的定制应用的下载方案同样可以适用于其他操作系统，本领域技术人员只需根据需要调用对应操作系统的功能即可，具体的实现方式，本实施例不作说明。
此外，在一个例子中，定制布局文件的格式为可扩展标记语言（eXtensibleMarkup Language，XML格式）。
此外，在实际的应用场景中，存储在数据分区（Data分区）中定制布局文件下载目录下的布局文件，除了可以是上述所说的定制布局文件，还可以有定制快捷布局文件等，此处不再一一列举，本实施例对此不做限制。
由此，实现了定制布局文件的下载。
此外，需要说明的是，关于定制布局的生效，可以分为热生效场景和重启场景。为了更好的理解 定制布局的生效，以下分别对这两种场景的生效流程进行说明。参见，图16，热生效场景的流程，具体包括：
步骤706，应用安装成功后，通知生效布局。
步骤707，定制OTA包存在定制布局且未生效过，生效定制OTA包中的布局。
具体的说，在生效定制布局时，先检测已经下载并存储在指定目录的定制OTA包中是否携带了定制布局文件，如果有则优先生效定制OTA包中携带的定制布局文件，而无需从Data分区中获取单独下载的定制布局文件，然后直接进入步骤710生效定制布局；否则，执行步骤708中的操作。
步骤708，未生效过布局且存在定制布局，从Data分区获取定制布局。
具体的说，如果定制OTA包中不存在定制布局文件，并且手机并未生效过布局，且Data分区中存在已下载好的定制布局文件，则直接从Data分区获取定制布局文件。
步骤709，返回定制布局。
步骤710，基于预设生效机制生效定制布局。
具体的，本实施例中基于预设生效机制生效定制布局的流程，具体如下：
（1）存在独立下载的定制布局，且定制布局未生效时，生效独立下载的定制布局，逐一获取APK的包名，根据安装状态生效图标；
（2）刷新独立下载的布局生效状态，后续不再更新，即在一个设备上仅生效一次某个批次的定制布局；
（3）生效完成后删除定制布局文件；
（4）用户清理桌面，支持恢复独立下载的定制布局。
由此，实现了在热生效场景下生效定制布局文件。
此外，关于重启场景下的定制布局生效的流程，参照图16，具体包括：
步骤711，应用安装成功后，通知生效布局。
步骤712，定制OTA包存在定制布局且未生效过，在桌面启动时即刻生效。
具体的说，在重启场景下，OUC在检测到手机重启时，会在重启过程中，直接访问存储在指定目录下的定制OTA包，并确定定制OTA包中是否存在定制布局文件，如果有，则直接在桌面启动时生效定制布局。
步骤713，未生效过布局且存在定制布局时，从Data分区获取定制布局。
步骤714，返回定制布局。
步骤715，基于预设生效机制生效定制布局。
需要说明的，在实际的应用场景中，重启场景下对定制布局生效所需的生效机制，与热生效场景下生效定制布局所依据的生效机制相同，此处不再赘述。
由此，实现了在重启效场景下生效定制布局文件。
此外，为了避免过度的占用存储空间，同时防止被恶意获取解读，定制布局生效后，可以直接从对应的目录删除定制布局文件。
此外，在实际的应用场景中，往往会存在原本所属用户群体为普通用户群体的用户需要转换为特定用户，从而能够采用本申请实施例提供的定制应用的下载方法进行应用的下载，平台侧子系统可以根据需要，将普通用户的用户类型信息修改为需要转网的运营商信息，从而无需用户更换设备、SIM卡等，便可以实现身份的转换。
可理解的，上述以定制OTA包业务场景进行具体描述，仅仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，本申请实施例提供的定制应用的下载方法，同样适用于通用渠道的应用的安装方式。
也就是说，存储在查询服务器中的信息是否需要以定制OTA包的形式进行存储，在向端侧需要安装应用的电子设备，如手机推送信息时，是否需要以定制OTA包的形式将定制OTA参数包、应用清单列表、定制布局文件一起推送给手机，并非本申请所要限制的地方，本申请的重点在于，将应用的源文件，如APK单独进行存储，从而实现不论是更新、还是安装，都能够对单一应用的APK进行操作，而非现有需要将所有不需要更改的应用的APK，以及参数资源全部下载到手机，然后根据全部下载的文件对手机本地安装的应用进行统一更改。
此外，可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
示例性的，图17示出了本申请实施例的一种装置200的示意性框图。装置200可包括：处理器201和收发器/收发管脚202，可选地，还包括存储器203。
装置200的各个组件通过总线204耦合在一起，其中，总线204除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图中将各种总线都称为总线204。
可选地，存储器203可以用于前述方法实施例中的指令。该处理器201可用于执行存储器203中的指令，并控制接收管脚接收信号，以及控制发送管脚发送信号。
装置200可以是上述方法实施例中的端侧的手机等能够安装定制应用的电子设备，或云端中专门存储定制应用的源文件的独立应用存储服务器，或推送定制应用清单的查询服务器。
其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
另外，本申请实施例还提供了一种应用的下载系统，包括：查询服务器、存储服务器和电子设备，所述电子设备分别与所述查询服务器和所述存储服务器进行数据交互，所述查询服务器和所述存储服务器进行数据交互；所述存储服务器，用于：存储可供电子设备安装的应用对应的源文件；以及，根据所述电子设备的请求向所述电子设备推送所述电子设备请求的应用对应的源文件；所述查询服务器，用于：获取所述存储服务器存储的所述应用对应的源文件的描述信息和所述源文件对应的地址信息，并建立所述描述信息和所述地址信息之间的映射关系；根据所述映射关系，向发起搜索请求的所述电子设备推送需要安装的所述应用的源文件所在的地址信息；所述电子设备，用于：向所述查询服务器发起搜索需要安装的应用的搜索请求，所述搜索请求携带了需要安装的所述应用的描述信息；从所述查询服务器反馈的所述地址信息对应的存储服务器获取需要安装的所述应用的源文件。这样，通过在查询服务器中提供各种可以安装在电子设备中的应用的源文件的描述信息与源文件对应的地址信息之间的映射关系，使得电子设备始终可以获取到需要安装的应用的源文件的地址信息，进而根据地址信息从对应的存储服务器获取源文件实现安装，解决了现有用户使用一个应用商店对应的查询服务器只能获取到该应用商店对应的存储服务器中存储的应用的源文件的技术问题。
示例性的，在实际的应用场景中，所述存储服务器为终端厂商服务器。
相应地，所述存储服务器中存储的源文件为终端厂商提供的应用的源文件。这样，实现了终端厂商自己发布的应用的独立管理与维护。
示例性的，在实际的应用场景中，所述存储服务器还可以为运营商服务器。
相应地，所述存储服务器中存储的源文件为运营商提供的定制应用的源文件。这样，实现了对运营商定制应用的独立管理与维护。
示例性的，在实际的应用场景中，所述存储服务器还可以为第三方应用商服务器。
相应地，所述存储服务器中存储的源文件为第三方应用对应的源文件。这样，实现了对第三方应用的独立管理与维护。
示例性的，在实际的应用场景中，所述查询服务器和所述存储服务器为同一个服务器，即将一个服务器的一部分内存划分为查询服务器，用来存储上述存储在查询服务器中的信息，将另一部分内存划分为存储服务器，用来存储可供电子设备安装的应用的源文件，这样，可以减少服务器的投入成本。
示例性的，在实际的应用场景中，所述查询服务器和所述存储服务器为不同的服务器。这样，查询服务器和存储服务器可以分别管理维护。
基于上述应用的下载系统，既可以实现运营商定制应用的下载，也可以实现非运营商应用的下载。关于运营商定制应用的下载方法，可以参见本申请中针对特定应用的下载系统和下载方法的描述，此处不再赘述。
另外，本申请实施例还提供了一种应用的下载方法，应用于应用的下载系统，所述系统包括：询服务器、存储服务器和电子设备，所述电子设备分别与所述查询服务器和所述存储服务器进行数据交互，所述查询服务器和所述存储服务器进行数据交互；所述方法包括：所述电子设备根据需要安装的应用的描述信息生成搜索请求，并向所述查询服务器发起所述搜索请求；所述查询服务器接收到所述搜索请求后，根据所述搜索请求中携带的需要安装的所述应用的描述信息查找本地存储的可供所述电子设备安装的应用对应的源文件的描述信息，确定目标描述信息；所述查询服务器根据记录了所述可供所述电子设备安装的应用对应的源文件的描述信息与所述源文件对应的地址信息的映射关系，确定与所述目标描述信息对应的源文件存在映射关系的目标地址信息；所述查询服务器向所述电子设备下发所述目标地址信息；所述电子设备从所述查询服务器反馈的所述目标地址信息对应的存储服务器获取需要安装的所述应用的源文件。这样，通过在查询服务器中提供各种可以安装在电子设备中的应用的源文件的描述信息与源文件对应的地址信息之间的映射关系，使得电子设备始终可以获取到需要安装的应用的源文件的地址信息，进而根据地址信息从对应的存储服务器获取源文件实现安装，解决了现有用户使用一个应用商店对应的查询服务器只能获取到该应用商店对应的存储服务器中存储的应用的源文件的技术问题。
示例性的，在所述存储服务器中存储有需要安装的所述应用的源文件时，所述目标地址信息为所述存储服务器的地址信息。这样，电子设备便可以直接从存储服务器获取需要安装的应用的源文件。
示例性的，在所述存储服务器中未存储需要安装的所述应用的源文件时，所述目标地址信息为所述源文件所在的源站的地址信息。这样，即便当前的存储服务器中没有存在电子设备搜索的需要安装的应用的源文件，查询服务器也可以向电子设备返回需要安装的应用的源文件实际所在的源站的地址信息，从而使得电子设备能够根据返回的源站的地址信息，直接跳转到源站下载需要安装的应用的源文件。
另外，本申请实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备/网络设备（例如查询服务器、独立应用存储服务器）上运行时，使得电子设备/网络设备执行上述相关方法步骤实现上述实施例中的定制应用的下载方法。
另外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的定制应用的下载方法。
另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的定制应用的下载方法。
其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
本申请各个实施例的任意内容，以及同一实施例的任意内容，均可以自由组合。对上述内容的任意组合均在本申请的范围之内。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备（可以是单片机，芯片等）或处理器（processor）执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（read only memory，ROM）、随机存取存储器（random access memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。
上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (9)

1.一种定制应用的下载系统，其特征在于，包括：终端厂商服务器、查询服务器、独立应用存储服务器和电子设备，所述终端厂商服务器分别与所述查询服务器和所述独立应用存储服务器进行数据交互，所述电子设备分别与所述查询服务器和所述独立应用存储服务器进行数据交互，所述查询服务器和所述独立应用存储服务器进行数据交互，所述电子设备由终端厂商根据运营商的定制需求定制；
所述独立应用存储服务器，用于：
存储运营商发布的定制应用对应的源文件；
以及，根据所述电子设备的请求向所述电子设备推送所述电子设备请求的定制应用对应的源文件；
所述终端厂商服务器，用于：
根据运营商提供的定制需求，确定不同型号的所述电子设备对应的市场类型、运营商类型和需要安装的定制应用；
从所述独立应用存储服务器获取需要安装的所述定制应用对应的源文件的描述信息；
建立不同型号的所述电子设备对应的所述市场类型、所述运营商类型和需要安装的所述定制应用的所述描述信息之间的映射关系，得到不同型号的所述电子设备对应的定制应用清单；其中，接入同一运营商网络的多个不同型号的电子设备对应的定制应用清单相同，或者不相同；
将所述定制应用清单发送至所述查询服务器进行存储；
所述终端厂商服务器，还用于：
根据运营商提供的定制需求，确定需要安装的所述定制应用对应的权限信息；
根据所述权限信息更新所述定制应用清单，并将更新后的所述定制应用清单发送至所述查询服务器；
所述查询服务器，用于：
存储所述终端厂商服务器提供的所述定制应用清单；
所述电子设备，用于：
在满足预装运营商发布的定制应用的预设条件时，获取本机信息，确定本机的型号、投入的市场类型和接入的运营商类型；
根据本机的所述型号、投入的所述市场类型和接入的所述运营商类型生成预装请求，并向所述查询服务器发送所述预装请求；
所述查询服务器，还用于：
根据所述预装请求中携带的所述电子设备的所述型号、投入的所述市场类型和接入的所述运营商类型，从多个所述定制应用清单中匹配出需要发送给所述电子设备的目标定制应用清单；
根据所述权限信息，确定所述目标定制应用清单中可供用户选择的定制应用和默认需要安装的定制应用，并向所述电子设备推送指示了可供用户选择的定制应用和默认需要安装的定制应用的所述目标定制应用清单；
所述电子设备，还用于：
根据所述目标定制应用清单显示可供用户查看的定制应用清单列表，所述定制应用清单列表中显示了可供下载的定制应用对应的描述信息；
在监测到对所述定制应用清单列表中任一可供用户选择的定制应用的选中操作后，向所述独立应用存储服务器请求用户选中的定制应用的源文件和默认需要安装的定制应用的源文件；
接收所述独立应用存储服务器下发的源文件，对所述源文件进行SHA256校验，在下载获得的所述源文件与所述目标定制应用清单中被选中的定制应用对应的源文件是同一个时，进行安装。
2.根据权利要求1所述的系统，其特征在于，所述查询服务器，还用于：
按照预设周期从独立应用存储服务器获取运营商提供的新的定制应用对应的源文件的描述信息，根据新的所述定制应用对应的源文件的描述信息对所述定制应用清单进行更新；
和/或，
按照预设周期从所述独立应用存储服务器获取发生变更的源文件对应的描述信息，并根据发生变更的所述源文件对应的描述信息更新本地存储的所述定制应用清单中对应的描述信息。
3.根据权利要求1所述的系统，其特征在于，所述独立应用存储服务器，还用于：
在检测到运营商提供了新的定制应用对应的源文件时，向所述查询服务器发送新的定制应用对应的源文件的描述信息，供所述查询服务器根据新的所述定制应用对应的源文件的描述信息对所述定制应用清单进行更新；
和/或，
在检测到已存储的所述定制应用对应的源文件发生变更，向所述查询服务器发送发生变更的源文件对应的描述信息，供所述查询服务器根据发生变更的所述源文件对应的描述信息更新本地存储的所述定制应用清单中对应的描述信息。
4.根据权利要求1所述的系统，其特征在于，所述独立应用存储服务器，还用于：
在向所述电子设备推送所述电子设备请求的定制应用对应的源文件时，记录推送时间和推送结果；
根据所述推送时间、所述推送结果、所述源文件的描述信息和所述电子设备的标示信息，生成日志信息。
5.根据权利要求1所述的系统，其特征在于，
所述终端厂商服务器，还用于：
根据运营商提供的定制需求，生成所述电子设备安装所述定制应用时采用的定制布局文件；
建立所述定制布局文件与所述定制应用清单的之间的第一映射关系，得到映射关系表；
将所述定制布局文件和所述映射关系表发送至所述查询服务器；
所述查询服务器，还用于：
根据所述映射关系表中记录的所述第一映射关系，将所述定制布局文件与所述定制应用清单进行绑定，并在向所述电子设备推送所述目标定制应用清单时，向所述电子设备推送绑定的所述定制布局文件。
6.根据权利要求5所述的系统，其特征在于，
所述终端厂商服务器，还用于：
根据运营商提供的定制需求，确定需要配置到所述电子设备中的定制参数资源；
建立所述定制参数资源与所述定制应用清单之间的第二映射关系，并将所述第二映射关系添加到所述映射关系表；
将所述定制参数资源和所述映射关系表发送至所述查询服务器；
所述查询服务器，还用于：
根据所述映射关系表中记录的所述第二映射关系，将所述定制参数资源与所述定制应用清单进行绑定，并在向所述电子设备推送所述目标定制应用清单时，向所述电子设备推送绑定的所述定制参数资源。
7.根据权利要求1所述的系统，其特征在于，所述终端厂商服务器，还用于：
统计并存储被运营商指定为定制应用的应用信息。
8.根据权利要求1至7任一项所述的系统，其特征在于，所述独立应用存储服务器的数量为一个。
9.根据权利要求1至7任一项所述的系统，其特征在于，所述独立应用存储服务器的数量与提供定制需求的运营商的个数相同，且每一所述独立应用存储服务器对应一个运营商。
CN202110876561.8A 2021-07-31 2021-07-31 定制应用的下载系统 Active CN113727333B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110876561.8A CN113727333B (zh) 2021-07-31 2021-07-31 定制应用的下载系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110876561.8A CN113727333B (zh) 2021-07-31 2021-07-31 定制应用的下载系统

Publications (2)

Publication Number Publication Date
CN113727333A CN113727333A (zh) 2021-11-30
CN113727333B true CN113727333B (zh) 2023-11-24

Family

ID=78674470

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110876561.8A Active CN113727333B (zh) 2021-07-31 2021-07-31 定制应用的下载系统

Country Status (1)

Country Link
CN (1) CN113727333B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116048324B (zh) * 2022-05-26 2023-10-20 荣耀终端有限公司 桌面管理方法、电子设备及存储介质
CN116700738B (zh) * 2022-09-20 2023-12-12 荣耀终端有限公司 应用管理方法、电子设备及系统
CN115309431B (zh) * 2022-09-29 2023-07-18 荣耀终端有限公司 一种参数更新方法、可读介质和电子设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102387165A (zh) * 2010-08-27 2012-03-21 腾讯科技（深圳）有限公司 软件升级系统及方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070169073A1 (en) * 2002-04-12 2007-07-19 O'neill Patrick Update package generation and distribution network
US8725745B2 (en) * 2009-04-13 2014-05-13 Microsoft Corporation Provision of applications to mobile devices
KR20140107713A (ko) * 2013-02-25 2014-09-05 한국전자통신연구원 통합 앱스토어 장치, 상기 장치에서의 애플리케이션 제공 방법 및 통합 앱스토어 시스템

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102387165A (zh) * 2010-08-27 2012-03-21 腾讯科技（深圳）有限公司 软件升级系统及方法

Also Published As

Publication number Publication date
CN113727333A (zh) 2021-11-30

Similar Documents

Publication Publication Date Title
CN113727333B (zh) 定制应用的下载系统
EP4002108B1 (en) Application start method and electronic device
US11134372B2 (en) Downloading profiles corresponding to subscriber identification modules in electronic device
US10560816B2 (en) Electronic device and method for setting software in electronic device
CN110569130B (zh) 一种跨进程通信方法、装置及设备
US11368360B2 (en) Electronic device, and software setting method based on subscriber identity module in electronic device
US20230054451A1 (en) Communication Connection Method and Electronic Device
CN110869907A (zh) 一种浏览应用页面的方法及终端
CN112988213B (zh) 一种程序数据更新方法、电子设备及计算机存储介质
CN115643338B (zh) 一种参数更新方法及设备
CN112783384A (zh) 一种云应用运行的控制方法及电子设备
CN110865837A (zh) 一种进行系统升级的方法和终端
CN115309431B (zh) 一种参数更新方法、可读介质和电子设备
CN110968331A (zh) 应用程序运行的方法和装置
CN115002747B (zh) 一种参数更新方法、系统、终端设备及芯片系统
WO2022052766A1 (zh) 主题包适配方法及装置
CN111158735B (zh) 一种热补丁文件处理方法及通信终端
CN116048563B (zh) 一种系统升级方法、电子设备以及存储介质
CN115314427A (zh) 一种协议测试方法、电子设备及芯片系统
CN117130808B (zh) 一种日志采集方法及电子设备
CN116662101B (zh) 电子设备的故障修复方法和电子设备
WO2024083114A1 (zh) 一种软件分发方法、电子设备及系统
CN117009023B (zh) 显示通知信息的方法及相关装置
CN118245078A (zh) 升级方法及其相关设备
CN115146293A (zh) 一种文件加、解密方法、设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant