CN109558164A - 安卓安装包打包方法及装置、电子设备、可读存储介质 - Google Patents

Abstract

本公开是关于一种安卓安装包打包方法及装置、电子设备、可读存储介质。一种安卓安装包打包方法，包括：从第一安卓安装包的预设区域获取所述第一安卓安装包的属性数据；修改所述属性数据；将修改后的属性数据写入所述第一安卓安装包的预设区域，得到第二安卓安装包。可见，本实施例中无需对安卓安装包进行解包和重压缩即可获取到安卓安装包的属性数据，减少打包时间。并且，本实施例中只需要修改属性数据，对安卓安装包的改进较小，可以进一步减少打包时间。换言之，本实施例中通过降低安卓安装包的打包时间，可以提升用户的工作效率。

Description

安卓安装包打包方法及装置、电子设备、可读存储介质

技术领域

本公开涉及软件工程技术领域，尤其涉及一种安卓安装包打包方法及装置、电子设备、可读存储介质。

背景技术

目前，很多公司的开发软件需要与平台(例如百度、豌豆荚等)合作，针对各个平台，对软件进行打包以生成安卓安装包(AndroidPackage，APK)安装包，然后将安卓安装包上传到各个平台。这样，用户可以从各个平台下载软件，这样有利于提高软件的下载量和安装量。

实际应用中，若软件有更新后，需要对软件重新打包。当软件数量较少时，用户可以针对各个平台对软件进行手动打包。但是，当软件数量较多时，用户需要利用相应的安卓安装包工具对软件进行处理，例如解包、修改以及重新打包，不但耗费时间较多，还会增加用户的工作量以及降低用户的工作效率。

发明内容

本公开提供一种安卓安装包打包方法及装置、电子设备、可读存储介质，以解决相关技术中的不足。

根据本公开实施例的第一方面，提供一种安卓安装包打包方法，包括：

从第一安卓安装包的预设区域获取所述第一安卓安装包的属性数据；

修改所述属性数据；

将修改后的属性数据写入所述第一安卓安装包的预设区域，得到第二安卓安装包。

可选地，所述第一安卓安装包和所述第二安卓安装包为Zip压缩格式的文件，且所述预设区域位于所述Zip压缩格式的文件的尾部。

可选地，所述属性数据包括渠道对应的识别码，所述方法还包括：

将所述第二安卓安装包发送至识别码对应的渠道。

可选地，所述第一安卓安装包和所述第二安卓安装包适于安装Android7.0版本的操作系统的电子设备。

可选地，所述方法还包括：

将所述Android 7.0版本的操作系统中签名配置选项signingConfigs修改为禁用V2签名增强模式。

根据本公开实施例的第二方面，提供一种安卓安装包打包装置，包括：

属性数据获取模块，用于从第一安卓安装包的预设区域获取所述第一安卓安装包的属性数据；

属性数据修改模块，用于修改所述属性数据；

属性数据写入模块，用于将修改后的属性数据写入所述第一安卓安装包的预设区域，得到第二安卓安装包。

可选地，所述第一安卓安装包和所述第二安卓安装包为Zip压缩格式的文件，且所述预设区域位于所述Zip压缩格式的文件的尾部。

可选地，所述属性数据包括渠道对应的识别码，所述装置还包括：

安装包发送模块，用于将所述第二安卓安装包发送至识别码对应的渠道。

可选地，所述第一安卓安装包和所述第二安卓安装包适于安装Android7.0版本的操作系统的电子设备。

可选地，所述装置还包括：

签名配置修改模块，用于将所述Android 7.0版本的操作系统中签名配置选项signingConfigs修改为禁用V2签名增强模式。

根据本公开实施例的第三方面，提供一种电子设备，所述电子设备包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器用于从所述存储器读取可执行指令以实现第一方面所述方法的步骤。

根据本公开实施例的第四方面，提供一种可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现第一方面所述方法的步骤。

本公开的实施例提供的技术方案可以包括以下有益效果：

由上述实施例可知，本公开实施例中通过从第一安卓安装包的预设区域获取第一安卓安装包的属性数据；然后，修改所述属性数据；最后，将修改后的属性数据写入第一安卓安装包的预设区域，得到第二安卓安装包。可见，本实施例中无需对安卓安装包进行解包和重压缩即可获取到安卓安装包的属性数据，减少打包时间。并且，本实施例中只需要修改属性数据，对安卓安装包的改进较小，可以进一步减少打包时间。换言之，本实施例中通过降低安卓安装包的打包时间，可以提升用户的工作效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种安卓安装包打包方法的流程示意图；

图2是根据一示例性实施例示出的另一种安卓安装包打包方法的流程示意图；

图3是根据一示例性实施例示出的又一种安卓安装包打包方法的流程示意图；

图4～图6是根据一示例性实施例示出的一种显示装置的框图；

图7是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置例子。

目前，很多公司的开发软件需要与平台(例如百度、豌豆荚等)合作，针对各个平台，对软件进行打包以生成安卓安装包，然后将安卓安装包上传到各个平台。这样，用户可以从各个平台下载软件，这样有利于提高软件的下载量和安装量。

实际应用中，若软件有更新后，需要对软件重新打包。当软件数量较少时，用户可以针对各个平台对软件进行手动打包。但是，当软件数量较多时，用户需要利用相应的安卓安装包工具对软件进行处理，例如解包、修改以及重新打包，不但耗费时间较多，还会增加用户的工作量以及降低用户的工作效率。

为解决上述技术问题，本公开实施例提供了一种安卓安装包打包方法，其构思在于，将安卓安装包需要修改的属性数据设置在安卓安装包的预设区域，该预设区域可以为安卓安装包的尾部。其中，属性数据至少包括渠道对应的识别码，渠道是指各个平台，该各个平台可以接收用户下载安卓安装包的需求，并反馈为软件开发公司；在软件开发公司可以接收的安卓安装包分发给有下载安装包需求的用户。这样，本实施例仅需要对安卓安装包的属性数据进行修改即可，而无需解包和重压缩，可以减少打包时间。

图1是根据一示例性实施例示出的一种安卓安装包打包方法，参见图1，适用安装Android操作系统的电子设备，一种安卓安装包打包方法包括步骤101～步骤103，其中：

在步骤101中，从第一安卓安装包的预设区域获取所述第一安卓安装包的属性数据。

本实施例中，安卓安装包至少包括压缩后的软件内容、安装包信息以及属性数据。其中安装包信息包括如下至少一项：压缩工具、压缩前后软件的变化以及压缩包的说明信息。属性数据至少包括如下至少一种：渠道对应的识别码、属性数据加密算法。并且，属性数据区别于压缩后的软件内容，可以设置在安卓安装包的预设区域。其中预设区域可以为安卓安装包的任意位置，在一实施例中，预设区域为安卓安装包的尾部。

需要说明的是，第一安卓安装包是指对升级后的软件进行压缩后形成的安装包，即需要重新打包的安装包。

还需要说明的是，本实施例中第一安卓安装包的压缩格式可以为rar、zip、cab、iso、jar、tar、gz、arj、uue、bz2和z中的一种。在一实施例中，第一安卓安装包可以为Zip压缩格式的文件。

本实施例中，电子设备从第一安卓安装包的预设区域获取该第一安卓安装包的属性数据，获取方式可以为：

方式一，调用预设算法，将第一安卓安装包作为预设算法的输入数据，由预设算法从第一安卓安装包的预设区域读取出属性数据。例如，属性数据可以为Comment值，则预设算法可以为getComment函数。

方式二，软件提供方可以采用人工从第一安卓安装包提取属性数据，然后再将属性数据输入到电子设备中。

需要说明的是，技术人员可以根据具体场景，设置不同的方式获取属性数据，相应方案同样落入本申请的保护范围。

在步骤102中，修改所述属性数据。

本实施例中，电子设备调用预设规则，然后按照预设规则修改属性数据，可以包括：

方式一，若预设规则是指不同渠道的识别码为顺序排序的数字，则电子设备可以按照顺序依次修改属性数据。例如，渠道1的识别码为0001，渠道2的识别为0002，以此类推。这样，电子设备在确定第一个渠道的标识码之后，可以按照相应步长确定第一个渠道之后渠道的标识码，方便快捷，减少计算量。

方式二，若预设规则是指单独为每个渠道分配的识别码，则电子设备可以确定出安卓安装包需要发送到的目标渠道，然后确定该目标渠道的识别码，然后将属性数据内包含的识别码修改为目标渠道的识别码。

方式三，若预设规则是指随机分配识别码，则电子设备可以将属性数据内包含的识别码随机修改为一个识别码，然后确定安卓安装包需要发送到的目标渠道，最后记录识别码和目标渠道的对应关系。

可理解的是，预设规则可以根据具体场景进行调整，在能够确定属性数据与渠道的对应关系的情况下，相应方案落入本申请的保护范围。

在步骤103中，将修改后的属性数据写入所述第一安卓安装包的预设区域，得到第二安卓安装包。

本实施例中，在修改完属性数据后，电子设备可以将修改后的属性数据再写入第一安卓安装包的预设区域，这样可以得到第二安卓安装包。换言之，第二安卓安装包和第一安卓安装包的区别在于属性数据不同。

在一些实施例中，电子设备执行一种安卓安装包打包方法后，打包一个安卓安装包所消耗时间小于10毫秒，在1秒内可以处理100多个安装包，在一些场景中，电子设备在1秒内可以打300多个安卓安装包，这样软件提供方可以在没有开发环境(例如AndroidStudio环境、Ubuntu操作系统环境、Java环境或Gradle构建环境)的情况下，也能对安卓安装包快速处理。

在一些实施例中，参见图2，电子设备可以将第二安卓安装包发送至对应的渠道(对应步骤104)。可理解的是，电子设备可以得到一个第二安卓安装包就发送到对应的渠道，还可以在获取到全部渠道对应的第二安卓安装包后再依次发送到对应的渠道，又可以在获取到预设数量的第二安卓安装包后再依次发送到对应的渠道。技术人员可以根据具体场景进行设置，在此不作限定。

实际应用中，电子设备可以安装Android操作系统，例如Android 7.0版本或Android 6.0版本等。然而，考虑到Android操作系统的安全性，Android7.0版本之后的版本增加了新的增加签名模式，即从Android Gradle Plugin2.2.0开始，构建系统在打包应用后签名时默认使用第二版安装包签名设计“APK signature scheme v2”。该APK signaturescheme v2在原有签名模式上，增加校验安卓安装包的SHA256哈希值。若对签名后的安卓安装包作了任何修改，安装时会校验失败，提示没有签名无法安装。为此，在一些实施例中，参见图3，在步骤101之前，电子设备将Android 7.0版本的操作系统中签名配置选项signingConfigs修改为禁用V2签名增强模式(对应步骤301)。这样，通过渠道下载的安卓安装包可以在安装有Android 7.0之后版本操作系统的电子设备上正常安装使用。

至此，本公开实施例中通过从第一安卓安装包的预设区域获取第一安卓安装包的属性数据；然后，修改所述属性数据；之后，将修改后的属性数据写入第一安卓安装包的预设区域，得到第二安卓安装包。最后，可以把第二安卓安装包发送到对应的渠道。可见，本实施例中无需对安卓安装包进行解包和重压缩即可获取到安卓安装包的属性数据，有利于减少打包时间。并且，本实施例中只需要修改安卓安装包的属性数据，对安卓安装包的改进较小且所消耗时间较少，可以进一步减少打包时间。换言之，本实施例中通过降低安卓安装包的打包时间即可以得到各渠道的安装包，可以提升用户的工作效率。

图4是根据一示例性实施例示出的一种安卓安装包打包装置，参见图4，适用安装Android操作系统的电子设备，一种安卓安装包打包装置400，包括：

属性数据获取模块401，用于从第一安卓安装包的预设区域获取所述第一安卓安装包的属性数据；

属性数据修改模块402，用于修改所述属性数据；

属性数据写入模块403，用于将修改后的属性数据写入所述第一安卓安装包的预设区域，得到第二安卓安装包。

至此，本公开实施例中通过从第一安卓安装包的预设区域获取第一安卓安装包的属性数据；然后，修改所述属性数据；之后，将修改后的属性数据写入第一安卓安装包的预设区域，得到第二安卓安装包。最后，可以把第二安卓安装包发送到对应的渠道。可见，本实施例中无需对安卓安装包进行解包和重压缩即可获取到安卓安装包的属性数据，有利于减少打包时间。并且，本实施例中只需要修改安卓安装包的属性数据，对安卓安装包的改进较小且所消耗时间较少，可以进一步减少打包时间。换言之，本实施例中通过降低安卓安装包的打包时间即可以得到各渠道的安装包，可以提升用户的工作效率。

在一些实施例中，第一安卓安装包和第二安卓安装包为Zip压缩格式的文件，且预设区域位于所述Zip压缩格式的文件的尾部。本实施例中，通过将安卓安装包的属性数据设置预设区域，这样可以提高获取属性数据的效率。另外，本实施例中将软件升级后安卓安装包中需要修改的数据放置在属性数据内，这样可以不用对安卓安装包进行解压，减少打包所用时间，提高打包效率。

图5是根据一示例性实施例示出的一种安卓安装包打包装置，参见图5，在图4所示的一种安卓安装包打包装置400的基础上，若属性数据包括渠道对应的识别码，该装置400还包括：

安装包发送模块501，用于将所述第二安卓安装包发送至识别码对应的渠道。

在一些实施例中，所述第一安卓安装包和所述第二安卓安装包适于安装Android7.0版本的操作系统的电子设备。

图6是根据一示例性实施例示出的一种安卓安装包打包装置，参见图6，在图4所示的一种安卓安装包打包装置400的基础上，该装置400还包括：

签名配置修改模块601，用于将所述Android 7.0版本的操作系统中签名配置选项signingConfigs修改为禁用V2签名增强模式。这样，通过渠道下载的安卓安装包可以在安装有Android 7.0之后版本操作系统的电子设备上正常安装使用。

另需要说明的是，本实施例提供的一种安卓安装包打包装置是基于图1～图3所示的安卓安装包打包方法实现的，具体内容可以参考图1～图3及所示实施例的内容，在此不再赘述。

图7是根据一示例性实施例示出的一种电子设备的框图。例如，电子设备700可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理或者服务器等。

参照图7，电子设备700可以包括以下一个或多个组件：处理组件702，存储器704，电源组件706，多媒体组件708，音频组件710，输入/输出(I/O)的接口712，传感器组件714，以及通信组件716。

处理组件702通常控制电子设备700的整体操作，诸如与显示，电话呼叫，数据通信和记录操作相关联的操作。处理组件702可以包括一个或多个处理器720来执行指令。此外，处理组件702可以包括一个或多个模块，便于处理组件702和其他组件之间的交互。例如，处理组件702可以包括多媒体模块，以方便多媒体组件708和处理组件702之间的交互。

存储器704被配置为存储各种类型的数据以支持在设备700的操作。这些数据的示例包括用于在电子设备700上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器704可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件706为电子设备700的各种组件提供电力。电源组件706可以包括电源管理系统，一个或多个电源，及其他与为电子设备700生成、管理和分配电力相关联的组件。

多媒体组件708包括在所述电子设备700和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示屏(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

音频组件710被配置为输出和/或输入音频信号。例如，音频组件710包括一个麦克风(MIC)，当电子设备700处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器704或经由通信组件716发送。在一些实施例中，音频组件710还包括一个扬声器，用于输出音频信号。

I/O接口712为处理组件702和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件714包括一个或多个传感器，用于为电子设备700提供各个方面的状态评估。例如，传感器组件714可以检测到电子设备700的打开/关闭状态，组件的相对定位，例如所述组件为电子设备700的显示屏和小键盘，传感器组件714还可以检测电子设备700或电子设备700一个组件的位置改变，用户与电子设备700接触的存在或不存在，电子设备700方位或加速/减速和电子设备700的温度变化。传感器组件714可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件714还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件714还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器，按键控制芯片、指纹传感器。

通信组件716被配置为便于电子设备700和其他设备之间有线或无线方式的通信。电子设备700可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件716经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件716还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，电子设备700可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现。

在示例性实施例中，还提供了一种包括指令的非临时性机器可读存储介质，例如包括指令的存储器704，上述指令可由电子设备700的处理器720执行。例如，所述非临时性机器可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本公开实施例还提供了一种机器可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现图1～图3所述安卓安装包打包方法的步骤。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (12)

1.一种安卓安装包打包方法，其特征在于，包括：

从第一安卓安装包的预设区域获取所述第一安卓安装包的属性数据；

修改所述属性数据；

将修改后的属性数据写入所述第一安卓安装包的预设区域，得到第二安卓安装包。

2.根据权利要求1所述的安卓安装包打包方法，其特征在于，所述第一安卓安装包和所述第二安卓安装包为Zip压缩格式的文件，且所述预设区域位于所述Zip压缩格式的文件的尾部。

3.根据权利要求1所述的安卓安装包打包方法，其特征在于，所述属性数据包括渠道对应的识别码，所述方法还包括：

将所述第二安卓安装包发送至识别码对应的渠道。

4.根据权利要求1所述的安卓安装包打包方法，其特征在于，所述第一安卓安装包和所述第二安卓安装包适于安装Android 7.0版本的操作系统的电子设备。

5.根据权利要求4所述的安卓安装包打包方法，其特征在于，所述方法还包括：

将所述Android 7.0版本的操作系统中签名配置选项signingConfigs修改为禁用V2签名增强模式。

6.一种安卓安装包打包装置，其特征在于，包括：

属性数据获取模块，用于从第一安卓安装包的预设区域获取所述第一安卓安装包的属性数据；

属性数据修改模块，用于修改所述属性数据；

属性数据写入模块，用于将修改后的属性数据写入所述第一安卓安装包的预设区域，得到第二安卓安装包。

7.根据权利要求6所述的安卓安装包打包装置，其特征在于，所述第一安卓安装包和所述第二安卓安装包为Zip压缩格式的文件，且所述预设区域位于所述Zip压缩格式的文件的尾部。

8.根据权利要求6所述的安卓安装包打包装置，其特征在于，所述属性数据包括渠道对应的识别码，所述装置还包括：

安装包发送模块，用于将所述第二安卓安装包发送至识别码对应的渠道。

9.根据权利要求6所述的安卓安装包打包装置，其特征在于，所述第一安卓安装包和所述第二安卓安装包适于安装Android 7.0版本的操作系统的电子设备。

10.根据权利要求9所述的安卓安装包打包装置，其特征在于，所述装置还包括：

签名配置修改模块，用于将所述Android 7.0版本的操作系统中签名配置选项signingConfigs修改为禁用V2签名增强模式。

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

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器用于从所述存储器读取可执行指令以实现权利要求1～5任一项所述方法的步骤。

12.一种可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现权利要求1～5任一项所述方法的步骤。