CN114462101A - 一种应用apk包的处理***、方法和装置 - Google Patents

Abstract

本申请公开了一种应用apk包的处理***、方法和装置，该处理***包括密钥***、主包生成***和打包***，其中：所述密钥***和所述主包生成***部署在本地，所述打包***部署在云端，所述打包***中包括多个打包子***；所述密钥***用于生成第一密钥和第二密钥；所述主包生成***用于根据所述第一密钥生成目标应用的apk包；所述打包***用于根据所述第二密钥对所述apk包进行重签名，以及将重签名后得到的渠道包分发给至少一个渠道。本申请实施例不仅可以避免单机架构带来的不稳定性，还可以提高apk包的重签名和分发效率，且渠道包的分发可以不受内网存储资源和出口带宽的限制，从而有效提高渠道包的分发能力。

Description

一种应用apk包的处理***、方法和装置

技术领域

本申请涉及应用技术领域，尤其涉及一种应用apk包的处理***、方法和装置。

背景技术

在一些应用场景中，可以将应用通过一个或多个互联网渠道推广给用户，以供用户下载并安装应用。通常，在通过互联网渠道推广应用时，可以将应用的apk进行重签名得到重签名后的渠道包，然后将渠道包分发给对应的互联网渠道以供用户下载。

然而，在目前的相关技术中，渠道包的构建和分发都是基于内网的单机架构实现的，单机架构不稳定且内网的存储资源和出口带宽都是受限的，导致渠道包的构建和分发效率较低。

发明内容

本申请实施例提供一种应用apk包的处理***、方法和装置，用于解决目前渠道包的构建和分发效率较低的问题。

为解决上述技术问题，本申请实施例是这样实现的：

第一方面，提出一种应用apk包的处理***，包括密钥***、主包生成***和打包***，其中：

所述密钥***和所述主包生成***部署在本地，所述打包***部署在云端，所述打包***中包括多个打包子***；

所述密钥***用于生成第一密钥和第二密钥；

所述主包生成***用于根据所述第一密钥生成目标应用的apk包；

所述打包***用于根据所述第二密钥对所述apk包进行重签名，以及将重签名后得到的渠道包分发给至少一个渠道。

第二方面，提出一种应用apk包的处理方法，包括：

接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

第三方面，提出一种应用apk包的处理装置，包括：

接收模块，接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

第一获取模块，获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

第二获取模块，根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

重签名和分发模块，根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

第四方面，提出一种电子设备，该电子设备包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：

接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

第五方面，提出一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：

接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

由于密钥***可以自动生成渠道包构建过程(包括apk包的生成和apk包的重签名)中所需的第一密钥和第二密钥，因此，可以提高密钥的生成效率，进而提高渠道包的构建效率；由于密钥***和主包生成***均部署在本地，因此，可以保证密钥的安全性以及apk包生成过程的安全性；由于打包***中可以包括多个子打包***，多个子打包***可以实现对apk包的重签名和分发，因此，不仅可以避免单机架构带来的不稳定性，还可以提高apk包的重签名和分发效率，此外，由于打包***部署在云端，并在云端将重签名后得到的渠道包分发给至少一个渠道，因此，渠道包的分发可以不受内网存储资源和出口带宽的限制，从而有效提高渠道包的分发能力。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术中的一种应用apk包的处理***的结构示意图；

图2是本申请的一个实施例应用apk包的处理***的结构示意图；

图3是本申请的一个实施例应用apk包的处理方法的流程示意图；

图4是本申请的一个实施例应用apk包的处理方法的流程示意图；

图5是本申请的一个实施例电子设备的结构示意图；

图6是本申请的一个实施例应用apk包的处理装置的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

目前，在推广某个应用时，可以在应用开发商的官网进行推广发布，此外，在某些应用场景下，也可以通过互联网渠道进行应用推广，比如，通过头条、快手和广告联盟等渠道进行应用推广。

在通过互联网渠道进行应用推广时，通常可以将应用的apk进行重签名得到重签名后的渠道包，然后将渠道包分发给对应的互联网渠道。然而，在目前的相关技术中，渠道包的构建和分发都是基于内网的单机架构实现的，单机架构不稳定且内网的存储资源和出口带宽都是受限的，导致渠道包的构建和分发效率较低。

如图1所示，图1是现有技术中的一种应用apk包的处理***的结构示意图。图1中的处理***(即图1所示的打包***)为单机架构(或单点架构)，用于对应用apk包进行重签名和分发的本机磁盘、apk签名密钥、数据库等核心基础支撑全部部署在单个服务器中。从图1可以看出，现有的处理***中任何一个小故障都会导致整个***服务不可用，核心密钥资源、相关的产品apk包以及重签名构建完成的渠道包资源均存在严重依赖主机磁盘存储资源的情况，渠道包的分发受限于内网的出口网络带宽和抢占带宽的能力，在渠道包的数据较多的情况下，会导致分发能力下降。此外，图1所示的处理***在构建渠道包时所使用的密钥均需要人工参与生成，导致密钥的生成效率低，进而导致渠道包的构建效率低。

为了解决上述技术问题，本申请实施例提供一种应用apk包的处理***，该处理***包括密钥***、主包生成***和打包***，其中：所述密钥***和所述主包生成***部署在本地，所述打包***部署在云端，所述打包***中包括多个打包子***；所述密钥***用于生成第一密钥和第二密钥；所述主包生成***用于根据所述第一密钥生成目标应用的apk包；所述打包***用于根据所述第二密钥对所述apk包进行重签名，以及将重签名后得到的渠道包分发给至少一个渠道。此外，本申请实施例还提供一种基于该处理***的应用apk包的处理方法和装置。

在本申请实施例提供的技术方案中，由于密钥***可以自动生成渠道包构建过程(包括apk包的生成和apk包的重签名)中所需的第一密钥和第二密钥，因此，可以提高密钥的生成效率，进而提高渠道包的构建效率；由于密钥***和主包生成***均部署在本地，因此，可以保证密钥的安全性以及apk包生成过程的安全性；由于打包***中可以包括多个子打包***，多个子打包***可以实现对apk包的重签名和分发，因此，不仅可以避免单机架构带来的不稳定性，还可以提高apk包的重签名和分发效率，此外，由于打包***部署在云端，并在云端将重签名后得到的渠道包分发给至少一个渠道，因此，渠道包的分发可以不受内网存储资源和出口带宽的限制，从而有效提高渠道包的分发能力。

需要说明的是，本申请实施例的应用场景可以是在对应用进行更新时，将更新后的apk包进行重签名后分发给至少一个互联网渠道的场景，也可以是在发布新的应用时，将新发布的应用的apk包进行重签名后分发给至少一个互联网渠道的场景。当然，也可以是将应用的某个特定版本的apk包进行重签名后分发给至少一个互联网渠道的场景，这里不做具体限定。互联网渠道可以简称为渠道，可以是头条、快手和广告联盟等渠道，也可以是其他互联网渠道，这里也不做具体限定。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图2是本申请的一个实施例应用apk包的处理***的结构示意图。

图2所示的处理***中包括密钥***21、主包生成***22和打包***23。其中，打包***23与密钥***21和主包生成***22部署在不同的位置，具体而言，密钥***21和主包生成***22可以均部署在本地，该本地可以是应用开发商的公司内网，打包***23可以部署在云端。从图2可以看出，本申请实施例提供的应用apk包的处理***为云端集群架构。

本申请实施例中，密钥***21可以用于生成第一密钥和第二密钥，第一密钥可以用于生成apk包，第二密钥可以用于对apk包进行重签名。主包生成***22可以用于根据密钥***21生成的第一密钥生成目标应用的apk包。打包***23可以用于根据密钥***21生成的第二密钥对目标应用的apk包进行重签名，以及将重签名后得到的渠道包分发给至少一个渠道。其中，打包***23中可以包括多个打包子***(图2仅以4个打包子***为例进行说明)，多个打包子***可以通过负载均衡的方式对目标应用的apk包进行重签名和分发，从而可以提高打包***的并发能力，进一步提升打包效率。

由于密钥***可以自动生成渠道包构建过程(包括apk包的生成和apk包的重签名)中所需的第一密钥和第二密钥，因此，可以提高密钥的生成效率，进而提高渠道包的构建效率；由于密钥***和主包生成***均部署在本地，因此，可以保证密钥的安全性以及apk包生成过程的安全性；由于打包***中可以包括多个子打包***，多个子打包***可以实现对apk包的重签名和分发，因此，不仅可以避免单机架构带来的不稳定性，还可以提高apk包的重签名和分发效率，此外，由于打包***部署在云端，并在云端将重签名后得到的渠道包分发给至少一个渠道，因此，渠道包的分发可以不受内网存储资源和出口带宽的限制，从而有效提高渠道包的分发能力。

在一种实现方式中，图2所示的密钥***21可以提供服务接口，密钥***可以通过该服务接口接入办公自动化(Office Automation，OA)***，OA***可以提供目标应用的产品核心基础信息，且OA***可以触发密钥***21生成第一密钥和第二密钥。其中，目标应用的产品的核心基础信息可以是目标应用的功能信息、版本信息等。

在密钥***接入OA***的情况下，密钥***在生成第一密钥和第二密钥时，可以包括：

根据目标应用的产品核心基础信息生成第二密钥；

对第二密钥进行指定的加密处理，生成第一密钥。

第二密钥和第一密钥可以是文件的形式，比如，第二密钥可以是jks文件，第一密钥可以是P12文件。可选地，在生成第一密钥和第二密钥后，可以将第一密钥和第二密钥分别写入对应的数据表中存储，以便后续可以提供给主包生成***和打包***使用。此外，在将第一密钥和第二密钥写入数据表后，还可以对数据表中的数据进行检查和验证，确保流程正确无误，然后可以返回给OA***已正确处理的response。

需要说明的是，在目前的相关技术中，上述第一密钥和第二密钥的生成需要人工干预，比如，需要人工构建密钥，人工将密钥同步到服务器等。而在本申请实施例中，通过对现有的密钥生成流程的各个环节进行分析，包括相关工具和脚本的分析，相关文件的前后依赖关系分析等，可以对密钥生成流程中需要人工干预的部分进行***化的等价替换，由此可以得到本申请实施例提供的密钥***，该密钥***可以自动生成第一密钥和第二密钥。具体而言，可以在密钥***中增设服务接口，通过服务接口接入到OA***，通过OA***触发密钥***自动化的构建第一密钥和第二密钥，这样，可以提高密钥的生成效率，进而提高渠道包的构建效率。

可选地，密钥***还可以支持可视化运营管理，以便追溯整个密钥生成流程，提升核心数据和流程的可运营的能力。具体地，密钥***可以支持包括jks文件(即第二密钥)信息的数据信息和P12文件(即第一密钥)的数据信息的展示，如果发现密钥生成流程某个环节出现问题，可以直接在密钥***中完成对应的密钥jks文件和P12文件的更新或者重建。

在一种实现方式中，密钥***还可以将第一密钥以第一密钥服务接口的形式封装，将第二密钥以第二密钥服务接口的形式封装，并对外提供该第一密钥服务接口和第二密钥服务接口。第一密钥服务接口可以用于主包生成***获取第一密钥进而生成目标应用的apk包，第二密钥服务接口可以用于打包***获取第二密钥进而对apk包进行重签名。

在密钥***提供第一密钥服务接口和第二密钥服务接口的情况下，密钥***还可以维护一份IP白名单，这样，当密钥***接收到密钥请求时，可以调用该IP白名单对密钥请求进行过滤，从而可以保护第一密钥和第二密钥的安全性，避免第一密钥和第二密钥被非法获取。

具体地，密钥***在接收到主包生成***针对第一密钥的密钥请求时，可以判断预先确定的白名单中是否包含密钥请求对应的IP地址，若是，则返回密钥请求所请求的第一密钥，若否，则可以不响应该密钥请求。同理，密钥***在接收到打包***针对第二密钥的密钥请求时，可以判断预先确定的白名单中是否包含密钥请求对应的IP地址，若是，则返回密钥请求所请求的第二密钥，若否，则可以不响应该密钥请求。

可选地，为了进一步保证密钥的安全性，密钥***在将第一密钥/第二密钥返回给主包生成***/打包***时，还可以以HTTPS的方式返回，以在第一密钥/第二密钥的传输过程中保证密钥的安全性。

本申请实施例提供的密钥***的可扩展性较高，不仅改进了现有的密钥流程的低效运行方式，同时为密钥的安全性和可靠性提供了根本保障；通过接入到OA***中，可以避免不必要的人工干预；支持的可视化运营能力可以有助于提升企业研发运营效率；建立名单信任机制，以HTTPS的方式提供核心的密钥数据服务，可以进一步提高安全性。

在一种实现方式中，主包生成***在根据第一密钥生成目标应用的apk包时，可以先从密钥***中获取与目标应用对应的第一密钥，然后使用第一密钥对目标应用需要发布的apk包或更新后的apk包进行加密，从而可以生成apk包。可选地，在从密钥***中获取与第一密钥时，可以通过密钥***提供的第一密钥服务解接口获取第一密钥。具体而言，可以通过该接口向密钥***发送密钥请求，密钥***在确定该密钥请求对应的IP地址是白名单的IP地址时，将对应的第一密钥返回给主包生成***。

主包生成***在生成apk包后，可以将apk包同步到云端的私有云存储中。其中，该私有云存储是目标应用的开发商在云端设置的私有云存储，在将apk包同步到云端的私有云存储时，可以通过调用打包服务接口进行同步。此外，还可以将该apk包对应的各种旧版本存储到私有云存储中，以便后续需要使用旧版本时可以从私有云存储中获取。

主包生成***在将apk包同步到云端的私有云存储后，还可以生成数据表，该数据表中可以记录apk包的包名、apk包的版本信息以及apk包在私有云存储中的存储路径，可选地，还可以记录apk包的大小、apk包的存储时间、更新或发布时间等信息。

在生成数据表后，主包生成***可以将数据表同步到打包***中。其中，数据表中的包名、版本信息和存储路径可以用于打包***对apk包进行重签名时从私有云存储中获取apk包，具体可以参见后续针对打包***的相关说明，这里不再详细描述。需要说明的是，打包***中的多个打包子***都可以独立地访问存储有apk包的私有云存储，从而可以实现apk包在多个打包子***中的共享。这样，通过私有云存储的方式将apk包提供给打包***中的任一打包子***使用，完全解耦了现有的单机架构中单节点存储资源依赖和限制的问题，使得核心资源具备共享能力。

在一种实现方式中，打包***在根据第二密钥对apk包进行重签名时，具体实现方式如下：

接收打包请求，打包请求中包括渠道号列表和apk包的产品信息

根据打包请求中的产品信息获取apk包；

从密钥***中获取第二密钥；

根据渠道号列表和第二密钥，对apk包进行重签名。

打包请求可以由开发人员或运营人员触发。具体而言，当需要将目标应用的apk包进行重签名并分发给至少一个渠道时，开发人员可以向打包***发送打包请求。打包请求中包括渠道号列表和目标应用的apk包的产品信息，该渠道号列表中可以包括与至少一个渠道对应的至少一个渠道号，渠道和渠道号之间可以是一一对应的关系，不同的渠道号用于区别不用的渠道apk包的产品信息中包括待分发的apk包的包名和版本信息。

打包***在接收到打包请求后，可以根据打包请求中的产品信息获取apk包，从密钥***中获取第二密钥，然后根据打包请求中的渠道号列表和获取到的第二密钥，对获取到的apk包进行重签名。需要说明的是，打包***中包括多个打包子***，打包***在接收到打包请求后，还可以通过负载均衡的机制，将打包请求交由某个打包子***进行处理，即由打包子***完成apk包和第二密钥的获取，以及apk包的重签名和分发，本申请实施例仅以整个打包***为例进行说明。

打包***在根据打包请求中的产品信息获取apk包时，可以从数据表中查找与产品信息对应的存储路径，然后根据查找到的存储路径从云端的私有云存储中获取该存储路径下的apk包。具体地，数据表可以是主包生成***在生成apk包后同步到打包***中的数据表，数据表中存储有apk包的包名、版本信息和存储路径，存储路径为主包生成***将生成的apk包存储到云端的私有云存储中时，apk包在私有云存储中的存储路径。这样，打包***在获取apk包时，可以根据打包请求中的产品信息，即apk包的包名和版本信息，在数据表中查找与该包名和版本信息对应的存储路径，根据该存储路径就可以在云端的私有云存储中获取到对应的apk包。

打包***在从密钥***中获取第二密钥时，可以通过密钥***提供的第二密钥服务解接口获取第二密钥。具体而言，可以通过该接口向密钥***发送密钥请求，密钥***在确定该密钥请求对应的IP地址是白名单的IP地址时，将对应的第二密钥返回给打包***。

打包***在根据渠道号列表和第二密钥，对apk包进行重签名时，首先，可以对apk包进行反解压，分析apk内部文件project.properties，剔除原有的密钥信息，即删除生成apk包时使用的第一密钥，然后根据渠道号列表中的至少一个渠道号和第二密钥，对apk包进行批量重签名，生成新的project.properties进而得到重签名后的渠道包。其中，针对一个渠道可以对应生成一个渠道包，不同的渠道包可以使用相同的第二密钥，也可以使用不同的第二密钥，这里不做具体限定。

可选地，考虑到对apk包进行批量重签名的过程是循环的过程，需要多次使用apk包和第二密钥，因此，打包***在获取到apk包和第二密钥后，还可以将apk包和第二密钥存储到指定目录下，这样，在对apk包进行重签名时，可以从指定目录下获取apk包和第二密钥，由此可以避免每次重签名时都重新获取apk包和第二密钥的问题，从而可以加快渠道包的构建效率。此外，在完成对apk包的重签名后，还可以删除指定目录下的apk包和第二密钥，从而可以避免apk包和第二密钥的泄露，提高安全性。

打包***在得到重签名后的apk包(即渠道包)后，可以将重签名后得到的渠道包分发给至少一个渠道。在一种实现方式中，打包***在将重签名后得到的渠道包分发给至少一个渠道时，可以通过多线程的方式将渠道包同步到云端的共有云存储中，然后对指定的内容分发网络(Content Delivery Network，CDN)进行刷新。具体而言，可以通过内部云存储内网调用的方式同步到云端的共有云存储中，待全部同步完成后，进行指定的CDN刷新，即可完成对外渠道包的下载内容更新。针对用户而言，可以通过更新后的下载链接下载apk包，然后安装目标应用。

本申请实施例中的打包***在对apk重签名和分发过程中，通过白名单机制和HTTPS的方式完成依赖密钥的获取，在使用完成后删除密钥，可以确保核心数据的安全性；在完成渠道包的重签名后并行同步到云端对应的云存储中，具备极高的同步分发效率，可以提升整个流程的并发度。

本申请实施例通过将现有的内网单体架构升级成云端的集群架构，可以提升apk渠道包的生成分发效率，升级改造后的云端集群架构中，打包***和密钥***都具备高可用性和可伸缩扩展的能力；打包***部署在云端，加上天然的云存储以及CDN结合的优势，成功解决了本地存储资源依赖的问题，同时也避开了网络出口带宽的问题，分发更新效率极速提升，使得整个***整体具备高可用性、高可扩展性和极高的分发效率。

图3是本申请的一个实施例应用apk包的处理处理方法的流程示意图。图3所示的实施例的执行主体可以是图2所示的打包***23，或者也可以是打包***23中的某个打包子***。图3所示的应用apk包的处理处理方法可以包括以下步骤。

S302：接收打包请求，打包请求中包括渠道号列表和apk包的产品信息，渠道号列表中包括至少一个渠道对应的渠道号，产品信息中包括apk包的包名和版本信息。

打包请求可以由开发人员或运营人员触发。具体而言，当需要将目标应用的apk包进行重签名并分发给至少一个渠道时，开发人员可以向打包***发送打包请求。打包请求中包括渠道号列表和目标应用的apk包的产品信息，该渠道号列表中可以包括与至少一个渠道对应的至少一个渠道号，渠道和渠道号之间可以是一一对应的关系，不同的渠道号用于区别不用的渠道apk包的产品信息中包括待分发的apk包的包名和版本信息。

S304：获取第二密钥，第二密钥由部署在本地的密钥***生成。

密钥***生成第二密钥的具体实现方式可以参见图2所示实施例中的相应描述，这里不再重复说明。打包***在接收到打包请求后，可以获取由密钥***生成的第二密钥。

S306：根据apk包的产品信息获取apk包，apk包由部署在本地的主包生成***根据第一密钥生成，第一密钥由密钥***生成。

主包生成***根据第一密钥生成apk包的具体实现以及密钥***生成第一密钥的具体实现均可以参见图2所示实施例中的相应描述，这里都不再重复说明。打包***在接收到打包请求后，还可以根据打包请求中的产品信息获取需要进行重签名的apk包。

S308：根据渠道号列表和第二密钥，对apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

上述S302至S308的具体实现方式可以参见图2所示实施例中相应步骤的具体实现，这里都不再重复说明。

为了便于理解本申请实施例提供的应用apk包的处理***，可以参见图4。图4是本申请的一个实施例应用apk包的处理方法的流程示意图。图4所示的实施例以apk版本更新的场景为例进行说明。

图4中包括密钥***、主包生成***和打包***，密钥***和主包生成***部署在本地，打包***部署在云端。在需要对应用的apk包更新版本进行重签名并分发给至少一个渠道时，具体实现方式如下。

密钥***可以根据产品核心基础信息自动生成jks文件(即第二密钥)，然后通过对jks文件进行加密可以生成P12文件(即第一密钥)。之后，可以将jks文件和P12文件存储到数据库中。此外，还可以通过第一密钥服务接口提供密钥P12文件接口服务以及通过第二密钥服务接口提供密钥jks文件接口服务，以分别供主包生成***和打包***使用。

主包生成***在apk版本更新的情况下，可以通过密钥P12文件接口服务获取P12文件，根据P12文件生成更新版本的apk包。然后通过调用云端的主包同步接口将apk包同步到云端的私有云存储中，同时还可以生成数据表，然后将数据表同步到打包***，数据表中记录有apk包的包名、版本信息以及在私有云存储中的存储路径。

运营人员向打包***发送打包请求，打包请求中包括渠道号列表和所述apk包的产品信息，渠道号列表中包括所述至少一个渠道对应的至少一个渠道号，产品信息中包括apk包的包名和版本信息。打包***在接收到打包请求后，可以根据打包请求中的产品信息在数据表中查找对应的存储路径，根据存储路径从私有云存储中获取该存储路径下的apk包，然后通过密钥***提供的密钥jks文件接口服务获取jks文件，最后根据渠道号列表和第二密钥，对apk包进行重签名得到渠道包。在得到渠道包后，可以通过多线程的方式将渠道包同步到云端的共有云存储中，并对指定的CDN进行刷新，从而可以完成对外渠道包的下载内容更新。

需要说明的是，图4中的打包***在接收到打包***后，还可以将打包***负载均衡到其中一个打包子***中(图4并未示出)，然后由该打包子***进行apk包的重签名和分发，这里仅以打包***为例进行说明。

为了更进一步说明，以下可以以对A产品的包名为test.com的apk包进行重签名和分发为例进行说明。

基于现有的单机架构，对apk包进行重签名和分发的流程如下：

步骤1、OA***触发密钥生成节点，对应的研发人员通过本地的keystore工具生成的密钥文件A.jks。

步骤2、通过rsync同步工具，将密钥文件A.jks同步到单点主机192.168.0.11主机的特定路径/data/keys/product/test.com/A.jks。

步骤3、手动运行主机192.168.0.11上的/data/keys/tools/build_p12_keys.py脚本，通过输入路径参数"data/keys/product/test.com/A.jks"，生成P12文件，并将P12文件写入到相同的路径/data/keys/product/test.com/A.P12，手动导出P12文件，再导入到用于生成apk包的jenkins***中。

步骤4、Jenkins***打包生成的主包apk，通过调用打包服务接口https:/pkg.xxx.com/apk/sync，在打包服务中将对应的主包写入到特定的主包路径/data/pkg/product/test.com/v1.1.1/unsigned.apk下。其中，v1.1.1指的是产品apk更新版本号，并且文件名统一为unsigned.apk，并将该同步记录写入数据表。

步骤5、打包***通过运营人员输入的参数：渠道号列表(1001～1888)、产品名A、产品包名test.com和对应的产品版本号v1.1.1，构建从1001到1888一共888个渠道包，并通过内网分发渠道包。

本申请实施例提供的技术方案对apk包的重签名和分发流程如下：

步骤1、OA***触发密钥生成节点，OA***直接调用密钥***提供的服务接口https://key.xxx.com/keys/build来完成后续的流程，直接替换现有的步骤1、2和3三个步骤。具体实现如下：

步骤1.1、等价改造现有的keystore工具的功能，直接完成密钥生成，然后写入数据表，数据表中可以包括产品名A，产品包名test.com，jks产品密钥：A.jks(二进制流格式)。

步骤1.2、等价改造现有的/data/keys/tools/build_p12_keys.py脚本的功能，将A.jks文件进行加密转化成A.P12文件，并追加产品A的P12密钥文件：A.P12(二进制流格式)。

步骤1.3、密钥***提供第一密钥服务接口和第二密钥服务接口，以供Jenkins***(即主包生成***)下载P12文件，以及打包***获取jks文件。

步骤2、Jenkins***打包生成的主包apk，通过调用打包服务接口https:/pkg.xxx.com/v2/apk/sync，在打包服务中将对应的主包同步到云端的私有云存储/cloud/storage/data/pkg/product/test.com/v1.1.1/unsigned.apk特定主包路径下，其中，v1.1.1指的是产品apk更新版本号，并且文件名统一为unsigned.apk,并将这些信息同步记录到数据表。

步骤3、打包***通过运营人员输入的参数：渠道号列表(1001～1888)、产品名A、产品包名test.com和对应的产品版本号v1.1.1，来构建从1001到1888一共888个渠道APK包。具体实现如下：

步骤3.1、打包***通过产品包名和版本号，从私有云存储获取对应的主包apk，即/cloud/storage/data/pkg/product/test.com/v1.1.1/unsigned.apk文件，并临时存储到运行服务节点的特定目录/data/tmp/pkg/test.com/v1.1.1/目录下

步骤3.2、通过组装产品包名参数，构建https request请求密钥***的https://key.xxx.com/keys/fetch接口来获取对应产品的A.jks文件，并将A.jks文件临时存储到运行服务节点的特定目录/data/tmp/pkg/test.com/v1.1.1/目录下。

步骤3.3、重签名工具脚本/data/pkg/tools/rebuild_signature.sh通过接收/data/tmp/pkg/test.com/v1.1.1/这个目录前缀参数，动态找到unsigned.apk和A.jks文件，加上渠道包信息，可以完成每个渠道包的重签名和构建，并输出到特定的分发路径下：/data/tmp/pkg/test.com/v1.1.1/distribution/。

步骤3.4、通过多线程并发的方式将待分发的渠道包以内部云存储内网调用的方式同步到公有云存储上，待全部同步完成后进行CDN刷新，即可更新下载链接的内容。

步骤3.5、清理/data/tmp/pkg/test.com/v1.1.1/这个目录和目录下的文件，完成全部流程。

假定公司内网带宽200MB/s，渠道包2000个，单个渠道包60MB左右，则待分发的渠道包大小：2000X 60MB＝120GB。

如果云主机和内网单机的机器硬件配置一致，那么，基于但是按内网架构的技术方案，在带宽完全占满的情况下，分发渠道包所需的耗时为：120GB/200(MB/s)＝600s＝10min。

而基于本申请实施例提供的云端集群架构，如果云端带宽为1GB/s，那么在云存储10个线程并行分发的情况下，耗时为：120GB/1(GB/s)/10＝120/10s＝12s。

由此可见，本申请实施例提供的云端集群架构可以具有秒级的分发能力，相较于内网的单点架构而言，分发能力较高。

基于本申请的上述各个实施例可知，在本申请实施例提供的技术方案中，由于密钥***可以自动生成渠道包构建过程(包括apk包的生成和apk包的重签名)中所需的第一密钥和第二密钥，因此，可以提高密钥的生成效率，进而提高渠道包的构建效率；由于密钥***和主包生成***均部署在本地，因此，可以保证密钥的安全性以及apk包生成过程的安全性；由于打包***中可以包括多个子打包***，多个子打包***可以实现对apk包的重签名和分发，因此，不仅可以避免单机架构带来的不稳定性，还可以提高apk包的重签名和分发效率，此外，由于打包***部署在云端，并在云端将重签名后得到的渠道包分发给至少一个渠道，因此，渠道包的分发可以不受内网存储资源和出口带宽的限制，从而有效提高渠道包的分发能力。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

图5是本申请的一个实施例电子设备的结构示意图。请参考图5，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成应用apk包的处理装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

上述如本申请图5所示实施例揭示的应用apk包的处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central ProcessingUnit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图3的方法，并实现应用apk包的处理装置在图3所示实施例中的功能，本申请实施例在此不再赘述。

当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图3所示实施例的方法，并具体用于执行以下操作：

接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

图6是本申请的一个实施例应用apk包的处理装置60的结构示意图。请参考图6，在一种软件实施方式中，所述应用apk包的处理装置60可包括：接收模块61、第一获取模块62、第二获取模块63和重签名和分发模块64，其中：

接收模块61，接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

第一获取模块62，获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

第二获取模块63，根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

重签名和分发模块64，根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

本申请实施例提供的应用apk包的处理装置60还可执行图3的方法，并实现应用apk包的处理装置在图3所示实施例的功能，本申请实施例在此不再赘述。

总之，以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

Claims (13)

1.一种应用apk包的处理***，其特征在于，所述处理***包括密钥***、主包生成***和打包***，其中：

所述密钥***和所述主包生成***部署在本地，所述打包***部署在云端，所述打包***中包括多个打包子***；

所述密钥***用于生成第一密钥和第二密钥；

所述主包生成***用于根据所述第一密钥生成目标应用的apk包；

所述打包***用于根据所述第二密钥对所述apk包进行重签名，以及将重签名后得到的渠道包分发给至少一个渠道。

2.如权利要求1所述的处理***，其特征在于，所述密钥***提供服务接口，所述密钥***通过所述服务接口接入办公自动化OA***，所述OA***提供所述目标应用的产品核心基础信息，所述OA***用于触发所述密钥***生成所述第一密钥和所述第二密钥；

其中，所述密钥***生成所述第一密钥和所述第二密钥，包括：

根据所述目标应用的产品核心基础信息生成所述第二密钥；

对所述第二密钥进行指定的加密处理，生成所述第一密钥。

3.如权利要求2所述的处理***，其特征在于，所述密钥***还提供第一密钥服务接口和第二密钥服务接口，所述第一密钥服务接口用于所述主包生成***获取所述第一密钥，所述第二密钥服务接口用于所述打包***获取所述第二密钥；

其中，所述密钥***在接收到密钥请求时，判断预先确定的白名单中是否包含所述密钥请求对应的IP地址；若是，则以HTTPS的方式返回所述密钥请求所请求的密钥。

4.如权利要求1所述的处理***，其特征在于，所述主包生成***根据所述第一密钥生成目标应用的apk包后，还包括：

将所述apk包同步到所述云端的私有云存储中；

生成数据表，并将所述数据表同步到所述打包***中；

其中，所述数据表中包括所述apk包的包名、版本信息和存储路径，所述数据表用于所述打包***对所述apk包进行重签名时从所述私有云存储中获取所述apk包。

5.如权利要求1所述的处理***，其特征在于，所述打包***根据所述第二密钥对所述apk包进行重签名，包括：

接收打包请求，所述打包请求中包括渠道号列表和所述apk包的产品信息，所述渠道号列表中包括所述至少一个渠道对应的至少一个渠道号，所述产品信息中包括所述apk包的包名和版本信息；

根据所述产品信息获取所述apk包；

从所述密钥***中获取所述第二密钥；

根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名。

6.如权利要求5所述的处理***，其特征在于，所述打包***根据所述产品信息获取所述apk包，包括：

从数据表中查找与所述产品信息对应的存储路径，所述数据表中存储有所述apk包的包名、版本信息和存储路径；

根据所述存储路径从所述云端的私有云存储中获取所述存储路径下的所述apk包。

7.如权利要求5所述的处理***，其特征在于，所述打包***根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，包括：

对所述apk包进行反解压，删除生成所述apk包时使用的所述第一密钥；

根据所述渠道号列表中的至少一个渠道号和所述第二密钥，对所述apk包进行批量重签名，得到重签名后的渠道包。

8.如权利要求5所述的处理***，其特征在于，所述打包***在获取所述apk包和所述第二密钥后，还包括：

将所述apk包和所述第二密钥存储到指定目录下；

在对所述apk包进行重签名时，从所述指定目录下获取所述apk包和所述第二密钥；

在完成对所述apk包的重签名后，删除所述指定目录下的所述apk包和所述第二密钥。

9.如权利要求1所述的处理***，其特征在于，所述打包***将重签名后得到的渠道包分发给至少一个渠道，包括：

通过多线程的方式将所述渠道包同步到所述云端的共有云存储中；

对指定的内容分发网络CDN进行刷新。

10.一种应用apk包的处理方法，其特征在于，包括：

接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

11.一种应用apk包的处理装置，其特征在于，包括：

接收模块，接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

第一获取模块，获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

第二获取模块，根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

重签名和分发模块，根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

12.一种电子设备，其特征在于，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：

接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：

接收打包请求，所述打包请求中包括渠道号列表和apk包的产品信息，所述渠道号列表中包括至少一个渠道对应的渠道号，所述产品信息中包括所述apk包的包名和版本信息；

获取第二密钥，所述第二密钥由部署在本地的密钥***生成；

根据所述apk包的产品信息获取所述apk包，所述apk包由部署在本地的主包生成***根据第一密钥生成，所述第一密钥由所述密钥***生成；

根据所述渠道号列表和所述第二密钥，对所述apk包进行重签名，并将重签名后得到渠道包分发给至少一个渠道。

Images