CN108459872A - 应用多渠道打包方法、装置、计算机设备及存储介质 - Google Patents

应用多渠道打包方法、装置、计算机设备及存储介质 Download PDF

Info

Publication number
CN108459872A
CN108459872A CN201810191443.1A CN201810191443A CN108459872A CN 108459872 A CN108459872 A CN 108459872A CN 201810191443 A CN201810191443 A CN 201810191443A CN 108459872 A CN108459872 A CN 108459872A
Authority
CN
China
Prior art keywords
files
document
clear packets
plaintext
channel
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.)
Granted
Application number
CN201810191443.1A
Other languages
English (en)
Other versions
CN108459872B (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.)
Ping An Technology Shenzhen Co Ltd
Original Assignee
Ping An Technology Shenzhen 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 Ping An Technology Shenzhen Co Ltd filed Critical Ping An Technology Shenzhen Co Ltd
Priority to CN201810191443.1A priority Critical patent/CN108459872B/zh
Priority to PCT/CN2018/085253 priority patent/WO2019169721A1/zh
Publication of CN108459872A publication Critical patent/CN108459872A/zh
Application granted granted Critical
Publication of CN108459872B publication Critical patent/CN108459872B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请公开了一种应用多渠道打包方法、装置、计算机设备及存储介质。该方法包括：获取apk安装包，通过第一脚本将apk安装包的后缀名调整至指定后缀名，并进行解压得到解压后文件；获取解压后文件中包括的多个子文件并分别进行SHA1运算，得到一一对应的文件摘要；将文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值并存储至子文件的目录中；在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；通过第三脚本将解压文件进行压缩，得到渠道包。该方法实现了渠道包打包自动化，简化了打渠道包的过程，提高了打包效率和成功率。

Description

应用多渠道打包方法、装置、计算机设备及存储介质
技术领域
本申请涉及安卓应用开发技术领域，尤其涉及一种应用多渠道打包方法、装置、计算机设备及存储介质。
背景技术
目前，Android应用(即安卓系统中的应用程序)在进行多渠道打包时，一般采用如下方案：
1)在AndroidManifest.xml文件中定义mate-data标签，设置渠道占位符；
2)在工程build.gradle文件下的productFlavors定义渠道号(其中，gradle文件是一个项目自动化构建工具；productFlavors用于定义产品的特性)；
采取上述方式进行多渠道打包时，每次增加一个渠道包时，需要修改build.gradle，还需在productFlavors定义渠道号，也即当需要配置多个渠道包就会执行相同次数的打包签名的操作，导致操作复杂。具体的，当每次开始打包都会修改AndroidManifest.xml文件，将渠道占位符替换为真实地渠道名称，然后在执行编译，开始一次完整的打包流程。所以多个渠道编译打包耗时＝每个渠道包编译的耗时总和＝(或者近似等于)N*一个渠道的编译打包时间，其中N为渠道总数目。而且在打包的过程中不能修改代码，以避免出错。通过这种方式实现多渠道打包非常耗时，生产效率很低。
发明内容
本申请提供了一种应用多渠道打包方法、装置、计算机设备及存储介质，旨在解决现有技术中进行多渠道打包时，每次增加一个渠道包时，需要修改build.gradle，还需在productFlavors定义渠道号，而且打包的过程中不能修改代码，导致打包效率低下，且容易出错的问题。
第一方面，本申请提供了一种应用多渠道打包方法，其包括：
获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；
获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；
将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；
在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；
通过第三脚本将解压文件进行压缩，得到渠道包。
第二方面，本申请提供了一种应用多渠道打包装置，其包括：
解压单元，用于获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；
文件摘要获取单元，用于获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；
编码单元，用于将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；
渠道名增加单元，用于在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；
渠道包打包单元，用于通过第三脚本将解压文件进行压缩，得到渠道包。
第三方面，本申请又提供了一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现本申请提供的任一项所述的应用多渠道打包方法。
第四方面，本申请还提供了一种存储介质，其中所述存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行本申请提供的任一项所述的应用多渠道打包方法。
本申请提供一种应用多渠道打包方法、装置、计算机设备及存储介质。该方法通过获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；通过第三脚本将解压文件进行压缩，得到渠道包。该方法实现了渠道包打包自动化，简化了打渠道包的过程，提高了打包效率和成功率。
附图说明
为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种应用多渠道打包方法的示意流程图；
图2是本申请实施例提供的一种应用多渠道打包方法的子流程示意图；
图3是本申请实施例提供的一种应用多渠道打包方法的另一子流程示意图；
图4为本申请实施例提供的一种应用多渠道打包方法的另一子流程示意图；
图5为本申请实施例提供的一种应用多渠道打包装置的示意性框图；
图6为本申请实施例提供的一种应用多渠道打包装置的子单元示意性框图；
图7为本申请实施例提供的一种应用多渠道打包装置的另一子单元示意性框图；
图8为本申请实施例提供的一种应用多渠道打包装置的另一子单元示意性框图；
图9为本申请实施例提供的一种计算机设备的示意性框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。
还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
请参阅图1，图1是本申请实施例提供的一种应用多渠道打包方法的示意流程图。该方法应用于台式电脑、手提电脑、平板电脑等终端中。如图1所示，该方法包括步骤S101～S105。
S101、获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件。
在本实施例中，在获取apk安装包后，通过第一脚本将apk安装包的后缀名调整至.zip(即预先设置的指定后缀名为.zip)。由于Android安装包是一个apk文件(因为是以.apk为后缀，所以也常称之为apk安装包)，其本身就是一个zip压缩文件，只是将.zip后缀修改为了.apk。
本申请中先通过第一脚本可以将.apk文件后缀修改为.zip的后缀名，然后用zip解压缩软件将其解压出来，解压之后一般包括META-INF、res、AndroidManifest.xml、classes.dex、resources.arsc这5个文件或目录。若要实现对apk安装包写入N个不同的渠道数据，此时获取了apk安装包后，是将其复制为N个apk安装包，每一apk安装包都通过第一脚本将apk安装包的后缀名由.apk修改为.zip，并解压得到解压后文件。本申请中修改后缀名是通过第一脚本脚本自动进行，无需用户手动修改，提高了后缀名修改的效率。
S102、获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要。
在一实施例中，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件。
如图2所示，所述步骤S102中将子文件分别进行SHA1运算，得到一一对应的文件摘要包括以下子步骤：
S1021、获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
S1022、获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
S1023、获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
S1024、获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
在本实施例中，对解压后文件中res文件、AndroidManifest.xml文件、classes.dex文件及resources.arsc文件这4个子文件的明文分别进行SHA1运算和后续的Base64编码，是为了对解压后文件进行数字签名，以确保应用程序包的安全性。本申请中选取res文件、AndroidManifest.xml文件、classes.dex文件及resources.arsc文件进行数字签名，并不对META-INF文件进行数字签名，是因为META-INF文件是用于存储签名信息的文件，无需对其进行数字签名。
如图3所示，所述步骤S1021中包括以下子步骤：
S10211、将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
S10212、将第一明文分组均分为16个32位的子明文分组；
S10213、创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
S10214、将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
S10215、对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
S10216、将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；
S10217、将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
S10218、将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
在本实施例中，按明文中总字符的个数除以512进行分组，若有余数所对应的分组中不足512个字符，则通过补充字符0将其补足至512字符(例如明文中有4800字符，4800除512的商为9余数为192，则将其明文分组为10组，其中只有192个字符中的一组明文分组中则补充320个0字符即可)。SHA1运算包括4轮运算，每一轮包括20个步骤，一共80步，当第1轮运算中的第1步骤开始处理时，A、B、C、D、E五个链接变量中的值先赋值到另外5个记录单元A′，B′，C′，D′，E′中。这5个值将保留，用于在第4轮的最后一个步骤完成之后与链接变量A，B，C，D，E进行求和操作。
SHA1的4轮运算，共80个步骤使用同一个操作程序，如下：
A,B,C,D,E←[(A<<<5)+ft(B,C,D)+E+Wt+Kt],A,(B<<<30),C,D
其中ft(B,C,D)为逻辑函数，Wt为子明文分组W[t](t＝0,1,2，……，79)，Kt为固定常数，Wt＝Mt(当0≤t≤15)，Wt＝(Wt-3⊕Wt-8⊕Wt-14⊕Wt-16)<<<1(当16≤t≤79)。这个操作程序的意义为：
将[(A<<<5)+ft(B,C,D)+E+Wt+Kt]的结果赋值给链接变量A；
将链接变量A初始值赋值给链接变量B；
将链接变量B初始值循环左移30位赋值给链接变量C；
将链接变量C初始值赋值给链接变量D；
将链接变量D初始值赋值给链接变量E。
SHA1规定4轮运算的逻辑函数如表1所示：
表1
在操作程序中需要使用固定常数Ki(i＝0，1，2，......79)，Ki的取值如表2所示：
轮数 步骤数(t) 函数定义
第一轮 0≤t≤19 Kt＝5A827999
第二轮 20≤t≤39 Kt＝6ED9EBA1
第三轮 40≤t≤59 Kt＝8F188CDC
第四轮 60≤t≤79 Kt＝CA62C1D6
表2
通过SHA1规定4轮运算得到第一明文分组的链接变量，以此类推，将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量。同样的，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要、将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要、将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要的过程均是参考将res文件的明文通过SHA1哈希算法运算得到第一文件摘要的计算过程。通过上述过程，能快速计算四个文件摘要。
S103、将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中。
在一实施例中，将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
BASE64是一种编码方式，通常用于把二进制数据编码为可写的字符形式的数据。这是一种可逆的编码方式。编码后的数据是一个字符串，其中包含的字符为A-Z、a-z、0-9、+、/共64个字符(26+26+10+1+1＝64)。完成上述四个文件摘要的SHA1运算和Base64编码，就实现了对安卓应用的数字签名，提高了其数据安全性。
S104、在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件。
如图4所示，该步骤S104中包括以下子步骤：
S1041、通过第二脚本在子文件的目录中创建空文件；
S1042、获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
在本实施例中，渠道标示文件就是空文件并通过第二脚本自动将该空文件的名称修改为待配置的渠道号，如以ssj开头，通过下划线连接渠道名，这样ssj_baidu就可以知道安卓应用的渠道名为baidu。且在解压文件的META-INF目录下包括了渠道标示文件这一空文件，则表示该解压文件就是一个包括了渠道数据的解压文件。若要实现通过第二脚本对N个apk安装包写入N个相对应的渠道数据，则是在每一个apk安装包解压后的META-INF目录下创建空文件，然后将空文件的名称根据待配置的渠道号相应修改；例如第一apk安装包解压后的META-INF目录下创建sjj_baidu名称的第一渠道标示文件(第一渠道标示文件是只以sjj_baidu命名的空文件)，第二apk安装包解压后的META-INF目录下创建sjj_tencent的第二渠道标示文件(同理，第二渠道标示文件是只以sjj_tencent命名的空文件)等。本申请中，通过在META-INF目录下创建空文件，并将空文件的名称修改为待配置的渠道号，通过简单的过程就实现了渠道包标识，提高了渠道包的打包效率。
S105、通过第三脚本将解压文件进行压缩，得到渠道包。
在本实施例中，通过第三脚本将解压文件进行压缩，也是一自动压缩的过程，无需用户手动操作。
可见，该方法实现了安卓应用打包自动化，无需手动配置打包工具的参数，也无需部署独立服务器，提高了打包效率和成功率。
本申请实施例还提供一种应用多渠道打包装置，该应用多渠道打包装置用于执行前述任一项应用多渠道打包方法。具体地，请参阅图5，图5是本申请实施例提供的一种应用多渠道打包装置的示意性框图。应用多渠道打包装置100可以安装于台式电脑、平板电脑、手提电脑、等终端中。
如图5所示，应用多渠道打包装置100包括解压单元101、文件摘要获取单元102、编码单元103、渠道名增加单元104、及渠道包打包单元105。
解压单元101，用于获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件。
在本实施例中，在获取apk安装包后，通过第一脚本将apk安装包的后缀名调整至.zip(即预先设置的指定后缀名为.zip)。由于Android安装包是一个apk文件(因为是以.apk为后缀，所以也常称之为apk安装包)，其本身就是一个zip压缩文件，只是将.zip后缀修改为了.apk。
本申请中先通过第一脚本可以将.apk文件后缀修改为.zip的后缀名，然后用zip解压缩软件将其解压出来，解压之后一般包括META-INF、res、AndroidManifest.xml、classes.dex、resources.arsc这5个文件或目录。若要实现对apk安装包写入N个不同的渠道数据，此时获取了apk安装包后，是将其复制为N个apk安装包，每一apk安装包都通过第一脚本将apk安装包的后缀名由.apk修改为.zip，并解压得到解压后文件。本申请中修改后缀名是通过第一脚本脚本自动进行，无需用户手动修改，提高了后缀名修改的效率。
文件摘要获取单元102，用于获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要。
在一实施例中，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件。
如图6所示，所述文件摘要获取单元102包括以下子单元：
第一文件摘要获取单元1021，用于获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
第二文件摘要获取单元1022，用于获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
第三文件摘要获取单元1023，用于获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
第四文件摘要获取单元1024，用于获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
在本实施例中，对解压后文件中res文件、AndroidManifest.xml文件、classes.dex文件及resources.arsc文件这4个子文件的明文分别进行SHA1运算和后续的Base64编码，是为了对解压后文件进行数字签名，以确保应用程序包的安全性。本申请中选取res文件、AndroidManifest.xml文件、classes.dex文件及resources.arsc文件进行数字签名，并不对META-INF文件进行数字签名，是因为META-INF文件是用于存储签名信息的文件，无需对其进行数字签名。
如图7所示，所述第一文件摘要获取单元1021包括以下子单元：
第一分组单元10211，用于将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
第二分组单元10212，用于将第一明文分组均分为16个32位的子明文分组；
链接变量创建单元10213，用于创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
分组扩展单元10214，用于将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
SHA1运算单元10215，用于对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
变量求和单元10216，用于将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；
重复计算单元10217，用于将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
变量串接单元10218，用于将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
在本实施例中，SHA1运算包括4轮运算，每一轮包括20个步骤，一共80步，当第1轮运算中的第1步骤开始处理时，A、B、C、D、E五个链接变量中的值先赋值到另外5个记录单元A′，B′，C′，D′，E′中。这5个值将保留，用于在第4轮的最后一个步骤完成之后与链接变量A，B，C，D，E进行求和操作。
通过SHA1规定4轮运算得到第一明文分组的链接变量，以此类推，将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量。同样的，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要、将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要、将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要的过程均是参考将res文件的明文通过SHA1哈希算法运算得到第一文件摘要的计算过程。通过上述过程，能快速计算四个文件摘要。
编码单元103，用于将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中。
在一实施例中，将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
BASE64是一种编码方式，通常用于把二进制数据编码为可写的字符形式的数据。这是一种可逆的编码方式。编码后的数据是一个字符串，其中包含的字符为A-Z、a-z、0-9、+、/共64个字符(26+26+10+1+1＝64)。完成上述四个文件摘要的SHA1运算和Base64编码，就实现了对安卓应用的数字签名，提高了其数据安全性。
渠道名增加单元104，用于在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件。
如图8所示，所述渠道名增加单元104包括以下子单元：
空文件创建单元1041，用于通过第二脚本在子文件的目录中创建空文件；
名称修改单元1042，用于获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
在本实施例中，渠道标示文件就是空文件并通过第二脚本自动将该空文件的名称修改为待配置的渠道号，如以ssj开头，通过下划线连接渠道名，这样ssj_baidu就可以知道安卓应用的渠道名为baidu。且在解压文件的META-INF目录下包括了渠道标示文件这一空文件，则表示该解压文件就是一个包括了渠道数据的解压文件。若要实现通过第二脚本对N个apk安装包写入N个相对应的渠道数据，则是在每一个apk安装包解压后的META-INF目录下创建空文件，然后将空文件的名称根据待配置的渠道号相应修改；例如第一apk安装包解压后的META-INF目录下创建sjj_baidu名称的第一渠道标示文件(第一渠道标示文件是只以sjj_baidu命名的空文件)，第二apk安装包解压后的META-INF目录下创建sjj_tencent的第二渠道标示文件(同理，第二渠道标示文件是只以sjj_tencent命名的空文件)等。本申请中，通过在META-INF目录下创建空文件，并将空文件的名称修改为待配置的渠道号，通过简单的过程就实现了渠道包标识，提高了渠道包的打包效率。
渠道包打包单元105，用于通过第三脚本将解压文件进行压缩，得到渠道包。
在本实施例中，通过第三脚本将解压文件进行压缩，也是一自动压缩的过程，无需用户手动操作。
可见，该装置实现了安卓应用打包自动化，无需手动配置打包工具的参数，也无需部署独立服务器，提高了打包效率和成功率。
上述应用多渠道打包装置可以实现为一种计算机程序的形式，该计算机程序可以在如图9所示的计算机设备上运行。
请参阅图9，图9是本申请实施例提供的一种计算机设备的示意性框图。该计算机设备500设备可以是终端。该终端可以是平板电脑、笔记本电脑、台式电脑、个人数字助理等电子设备。
参阅图9，该计算机设备500包括通过系统总线501连接的处理器502、存储器和网络接口505，其中，存储器可以包括非易失性存储介质503和内存储器504。
该非易失性存储介质503可存储操作系统5031和计算机程序5032。该计算机程序5032包括程序指令，该程序指令被执行时，可使得处理器502执行一种应用多渠道打包方法。
该处理器502用于提供计算和控制能力，支撑整个计算机设备500的运行。
该内存储器504为非易失性存储介质503中的计算机程序5032的运行提供环境，该计算机程序5032被处理器502执行时，可使得处理器502执行一种应用多渠道打包方法。
该网络接口505用于进行网络通信，如发送分配的任务等。本领域技术人员可以理解，图9中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备500的限定，具体的计算机设备500可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
其中，所述处理器502用于运行存储在存储器中的计算机程序5032，以实现如下功能：获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；通过第三脚本将解压文件进行压缩，得到渠道包。
在一实施例中，处理器502还执行如下操作：获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要；其中，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件。
在一实施例中，处理器502还执行如下操作：将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；将第一明文分组均分为16个32位的子明文分组；创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
在一实施例中，处理器502还执行如下操作：将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
在一实施例中，处理器502还执行如下操作：通过第二脚本在子文件的目录中创建空文件；获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
本领域技术人员可以理解，图9中示出的计算机设备的实施例并不构成对计算机设备具体构成的限定，在其他实施例中，计算机设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。例如，在一些实施例中，计算机设备可以仅包括存储器及处理器，在这样的实施例中，存储器及处理器的结构及功能与图9所示实施例一致，在此不再赘述。
应当理解，在本申请实施例中，处理器502可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器502还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable GateArray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
在本申请的另一实施例中提供一种存储介质。该存储介质可以为非易失性的计算机可读存储介质。该存储介质存储有计算机程序，其中计算机程序包括程序指令。该程序指令被处理器执行时实现：获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；通过第三脚本将解压文件进行压缩，得到渠道包。
在一实施例中，该程序指令被处理器执行时实现：获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要；其中，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件。
在一实施例中，该程序指令被处理器执行时实现：将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；将第一明文分组均分为16个32位的子明文分组；创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
在一实施例中，该程序指令被处理器执行时实现：将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
在一实施例中，该程序指令被处理器执行时实现：通过第二脚本在子文件的目录中创建空文件；获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
所述存储介质可以是前述设备的内部存储单元，例如设备的硬盘或内存。所述存储介质也可以是所述设备的外部存储设备，例如所述设备上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(SecureDigital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储介质还可以既包括所述设备的内部存储单元也包括外部存储设备。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的设备、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，也可以将具有相同功能的单元集合成一个单元，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种应用多渠道打包方法，其特征在于，包括：
获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；
获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；
将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；
在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；
通过第三脚本将解压文件进行压缩，得到渠道包。
2.根据权利要求1所述的应用多渠道打包方法，其特征在于，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件；
所述将子文件分别进行SHA1运算，得到一一对应的文件摘要，包括：
获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
3.根据权利要求2所述的应用多渠道打包方法，其特征在于，所述获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要，包括：
将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
将第一明文分组均分为16个32位的子明文分组；
创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；
将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
4.根据权利要求2所述的应用多渠道打包方法，其特征在于，所述将与文件摘要一一对应的哈希值存储至子文件的目录中，将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
5.根据权利要求1所述的应用多渠道打包方法，其特征在于，所述在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，包括：
通过第二脚本在子文件的目录中创建空文件；
获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
6.一种应用多渠道打包装置，其特征在于，包括：
解压单元，用于获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；
文件摘要获取单元，用于获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；
编码单元，用于将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；
渠道名增加单元，用于在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；
渠道包打包单元，用于通过第三脚本将解压文件进行压缩，得到渠道包。
7.根据权利要求6所述的应用多渠道打包装置，其特征在于，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件；
所述文件摘要获取单元，包括：
第一文件摘要获取单元，用于获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
第二文件摘要获取单元，用于获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
第三文件摘要获取单元，用于获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
第四文件摘要获取单元，用于获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
8.根据权利要求7所述的应用多渠道打包装置，其特征在于，所述第一文件摘要获取单元，包括：
第一分组单元，用于将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
第二分组单元，用于将第一明文分组均分为16个32位的子明文分组；
链接变量创建单元，用于创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
分组扩展单元，用于将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
SHA1运算单元，用于对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
变量求和单元，用于将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；
重复计算单元，用于将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
变量串接单元，用于将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
9.一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1-5中任一项所述的应用多渠道打包方法。
10.一种存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如权利要求1-5任一项所述的应用多渠道打包方法。
CN201810191443.1A 2018-03-08 2018-03-08 应用多渠道打包方法、装置、计算机设备及存储介质 Active CN108459872B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201810191443.1A CN108459872B (zh) 2018-03-08 2018-03-08 应用多渠道打包方法、装置、计算机设备及存储介质
PCT/CN2018/085253 WO2019169721A1 (zh) 2018-03-08 2018-05-02 应用多渠道打包方法、装置、计算机设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810191443.1A CN108459872B (zh) 2018-03-08 2018-03-08 应用多渠道打包方法、装置、计算机设备及存储介质

Publications (2)

Publication Number Publication Date
CN108459872A true CN108459872A (zh) 2018-08-28
CN108459872B CN108459872B (zh) 2019-12-24

Family

ID=63216763

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810191443.1A Active CN108459872B (zh) 2018-03-08 2018-03-08 应用多渠道打包方法、装置、计算机设备及存储介质

Country Status (2)

Country Link
CN (1) CN108459872B (zh)
WO (1) WO2019169721A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109388918A (zh) * 2018-11-02 2019-02-26 深圳市小牛普惠投资管理有限公司 资源包加密方法、装置、计算机设备及存储介质
CN109656572A (zh) * 2018-11-14 2019-04-19 深圳壹账通智能科技有限公司 安装包的打包方法及装置、计算机设备、存储介质
CN111596931A (zh) * 2020-05-27 2020-08-28 北京学之途网络科技有限公司 应用程序封装方法、装置、电子设备及可读存储介质
CN112860646A (zh) * 2021-02-24 2021-05-28 上海泰宇信息技术股份有限公司 一种海量文件档案分布式聚合压缩与单一式抽取的策略

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104317625A (zh) * 2014-11-09 2015-01-28 刘鹏 一种apk文件的动态加载方法
CN105893860A (zh) * 2016-05-05 2016-08-24 百度在线网络技术（北京）有限公司 关键代码保护方法以及代码生成装置和代码运行装置
US9762385B1 (en) * 2015-07-20 2017-09-12 Trend Micro Incorporated Protection of program code of apps of mobile computing devices
CN107169370A (zh) * 2017-04-21 2017-09-15 广州优视网络科技有限公司 可执行文件的加密方法及加密装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104317625A (zh) * 2014-11-09 2015-01-28 刘鹏 一种apk文件的动态加载方法
US9762385B1 (en) * 2015-07-20 2017-09-12 Trend Micro Incorporated Protection of program code of apps of mobile computing devices
CN105893860A (zh) * 2016-05-05 2016-08-24 百度在线网络技术（北京）有限公司 关键代码保护方法以及代码生成装置和代码运行装置
CN107169370A (zh) * 2017-04-21 2017-09-15 广州优视网络科技有限公司 可执行文件的加密方法及加密装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109388918A (zh) * 2018-11-02 2019-02-26 深圳市小牛普惠投资管理有限公司 资源包加密方法、装置、计算机设备及存储介质
CN109388918B (zh) * 2018-11-02 2020-07-28 深圳市小牛普惠投资管理有限公司 一种资源包加密方法、装置、计算机设备及存储介质
CN109656572A (zh) * 2018-11-14 2019-04-19 深圳壹账通智能科技有限公司 安装包的打包方法及装置、计算机设备、存储介质
CN111596931A (zh) * 2020-05-27 2020-08-28 北京学之途网络科技有限公司 应用程序封装方法、装置、电子设备及可读存储介质
CN112860646A (zh) * 2021-02-24 2021-05-28 上海泰宇信息技术股份有限公司 一种海量文件档案分布式聚合压缩与单一式抽取的策略
CN112860646B (zh) * 2021-02-24 2022-12-02 上海泰宇信息技术股份有限公司 一种海量文件档案分布式聚合压缩与单一式抽取的方法

Also Published As

Publication number Publication date
WO2019169721A1 (zh) 2019-09-12
CN108459872B (zh) 2019-12-24

Similar Documents

Publication Publication Date Title
CN108459872A (zh) 应用多渠道打包方法、装置、计算机设备及存储介质
CN104364756B (zh) 单个数据缓冲器的并行处理
CN104717179B (zh) 一种通信业务的处理方法及装置
CN104503745B (zh) 一种生成应用渠道包的方法和装置
CN111182025A (zh) 一种报文处理方法、装置、服务器及存储介质
Adj et al. Computing discrete logarithms in and using magma
US9288051B2 (en) Secure key management
CN107621973A (zh) 一种跨集群的任务调度方法及装置
CN110169012A (zh) 用于在区块链上实现复杂功能性同时保留对脚本大小和操作码限值的基于安全性限制的计算机实现的系统和方法
US20200293361A1 (en) Method and distributed database system for computer-aided execution of a program code
CN104111832A (zh) 一种安卓应用程序安装包加壳方法及系统及解壳方法
CN106502715A (zh) 一种应用程序多渠道配置方法及装置
CN111596920B (zh) 文件编译方法、装置、编译设备及存储介质
CN108897543A (zh) 版本的临时编译系统、方法、装置及存储介质
CN108519874A (zh) Python项目包的生成方法及装置
CN108717461A (zh) 海量数据结构化方法、装置、计算机设备及存储介质
CN104965760A (zh) 一种管理软件功能模块生命周期的方法和装置
CN109992278A (zh) 一种基于容器的应用程序发布方法及装置
CN108415894A (zh) 报表数据初始化方法、装置、计算机设备及存储介质
CN116318660B (zh) 一种消息扩展与压缩方法及相关装置
CN115840787B (zh) 基于区块链的供应链数据共享方法、装置、设备及介质
CN114595466A (zh) 实现对经加密的数据的机会认证
WO2017056073A1 (en) Method and system for compressing and/or encrypting data files
US8225100B2 (en) Hash functions using recurrency and arithmetic
CN110532236A (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