安卓多自定义属性安装包自动生成方法、系统及存储介质与流程

文档序号:14940715发布日期:2018-07-13 20:40阅读:171来源:国知局

本发明涉及安卓androidapp安装包打包领域,具体涉及一种安卓多自定义属性安装包自动生成方法、系统及存储介质。



背景技术:

本发明属于android商业应用开发的必经环节——生成对应各大android应用市场的app安装包;自2007年android发布起,官方只提供了ide生成安装包的方式,后续google官方将android应用开发方案升级,引入gradle来对项目代码进行配置并实现了使用命令生成安装包,但由于各个应用市场的对应的安装包配置均不相同,所以需要多次修改配置并运行ide或执行命令来生成一个个的安装包,整个过程步骤重复度高、繁琐且浪费时间,一直未能出现便捷的解决方案以实现全自动化配置并生成对应安装包。由于国内几乎任何一家需要发布android应用的企业必须要将其app投放到各大应用市场(渠道)并根据app对应的渠道标识来监测各个市场的下载量,此外还要改变app所连接的服务器(发布时会一般会由测试服务器转到线上服务器)、设置app的版本号并让app从开发中的debug版转为生成release版,所以该环节成为了开发效率上的一个瓶颈。一般一个10~15mb大小的安装包生成时间在2分钟左右,国内的应用市场有20个以上,加上人工修改配置并运行ide或命令以生成安装包的时间,每一次为发布新版生成安装包都要耗费1小时左右。

基于上述问题,本发明提出了一种高效且实际验证可行的多自定义属性安装包的批量生成方法。



技术实现要素:

本发明的目的是提供一种安卓多自定义属性安装包自动生成方法、系统及存储介质,可按照需求进行全自动化的多安装包生成,免去了人力的重复配置操作,大大解放了人力,极大地提高了工作效率和准确率。

为解决上述问题,本发明的第一方面提供了一种android多自定义属性安装包自动生成方法,包括如下步骤:

s1、填写自定义属性列表文件;

s2、设置多自定义属性自动打包脚本的android应用程序工程代码的源文件路径和生成的安装包的保存路径;

s3、将自定义属性列表文件和多自定义属性自动打包脚本放置于同一目录;

s4、运行所述多自定义属性自动打包脚本;

s5、生成与所述自定义属性列表文件中多个自定义属性一一对应的安装包并存储于步骤s2中设置的保存路径;

s6、对工程代码进行清理;

s7、删除运行所述多自定义属性自动打包脚本过程中生成的备份文件。

进一步地,所述自定义属性包括渠道标识、版本号和区分release和/或debug的标识、正式或测试服务器标识和业务类型标识;所述release是指对外发布或投放到应用商店的app版本,有签名、加密的保护机制,运行时不会产生调试日志;所述debug指用于开发调试的app版本,不具有保护机制,且运行时会产生调试日志。

进一步地,所述步骤s1具体为:将各个自定义属性名称及其相应配置写入所述自定义属性列表文件中,每个自定义属性名称及其相应配置占一行,中间以空格隔开,以换行符作为每个自定义属性名称及其相应配置结束的标识。

进一步地,所述步骤s4的运行过程中包括输入所述标识作为参数。

进一步地,所述步骤s4中运行所述多自定义属性自动打包脚本包括如下步骤:

s41、创建保存生成的安装包的文件目录;

s42、对工程代码执行清理和同步;

s43、从自定义属性列表文件中按顺序读取一个自定义属性名称及其相应配置;

s44、对工程代码中原有的自定义属性名称及其相应配置进行备份,并将步骤s43读取的自定义属性名称及其相应配置替换原有的自定义属性名称及其相应配置;

s45、根据输入的参数生成对应自定义属性名称的打包命令,并执行所述打包命令;

s46、生成的单个安装包存储到默认位置;

s47、将所述生成的单个安装包自动拷贝到的所述步骤s2的保存路径中;

s48、从步骤s44的备份文件中恢复工程代码的原有的自定义属性名称及其相应配置;

s49、返回步骤s43读取下一个自定义属性名称及其相应配置,直至所有的自定义属性名称及其相应配置读取完成以及所有对应安装包生成完毕。

进一步地,所述步骤s41中根据带入的版本号参数,创建名为版本号的文件目录以保存所述生成的安装包。

进一步地,所述步骤s42中的清理步骤用于原有生成文件的清理,防止无用生成文件干扰打包流程;所述同步步骤用于检查工程代码是否存在编译错误,若出错则终止打包流程。

进一步地,所述步骤s44具体为:读取出一个自定义属性名称及相应配置后,定位到工程代码配置文件中标识所述自定义属性名称及相应配置的位置,将原有的标识默认自定义属性名称的配置代码复制到临时备份文件中,若临时备份文件不存在则需要先创建,然后将读出的自定义属性名称按规定的格式填写好并替换掉原有的自定义属性名称的配置代码。

进一步地,所述步骤s7删除的备份文件为所述步骤s44执行过程中生成的所述临时备份文件。

进一步地,所述步骤s45中,若无对应的输入参数,则参数为工程代码配置文件中各类自定义属性的默认参数。

本发明的另一方面提供了一种android多自定义属性安装包自动生成系统,包括:

存储器以及一个或多个处理器;

其中,所述存储器与所述一个或多个处理器通信连接,所述存储器中存储有可被所述一个或多个处理器执行的指令,所述指令被所述一个或多个处理器执行,以使所述一个或多个处理器用于执行前面所述的方法。

本发明的又一方面提供了一种计算机可读存储介质,其上存储有计算机可执行指令,当所述计算机可执行指令被计算装置执行时,可操作来执行前面所述的方法。

综上所述,本发明提供了一种android多自定义属性安装包自动生成方法、系统及其计算机可读存储介质,所述自动生成方法利用官方提供的单个安装包的命令行生成方式自动生成多个按需求定制的安装包,所述按需求定制体现为将flavor标识的多自定义属性(包括多渠道、多连接服务器、多业务类型等)写入列表文件,然后每次读取一个自定义属性名称并替换工程代码中原有的自定义属性配置代码,通过上述方法来生成定制化的安装包。所述安装包自动生成方法采用全自动化的流程代替人力完成了诸多需要手动修改的操作,大大提升了效率,且避免了手动修改可能带来的错误并解放了人力。

本发明的上述技术方案具有如下有益的技术效果:

(1)当下仅有google官方提供的单个安装包的ide生成或命令行生成方式,还未有全自动化的多自定义属性(如渠道)生成方式,本方法弥补了这一空白;

(2)在每次生成完一个执行文件后就进行原始配置文件的恢复,以防止干扰下一次打包流程,或因为后续流程出错中断,导致配置文件无法被恢复;

(3)每次只读取一类属性中的一个属性名称及其相应配置并写入配置文件,若一次写入一类属性的多个属性名称及其相应配置,则打包时会同样扫描此次打包不会用上的属性名称及其相应配置,影响效率;

(4)全自动化的流程代替人力完成了诸多需要手动修改的操作,大大提升了效率和准确率,且解放了人力。

附图说明

图1是本发明的方法总流程图;

图2是本发明的自动打包脚本执行流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明了,下面结合具体实施方式并参照附图,对本发明进一步详细说明。应该理解,这些描述只是示例性的,而并非要限制本发明的范围。此外,在以下说明中,省略了对公知结构和技术的描述,以避免不必要地混淆本发明的概念。

google官方只提供了2种安装包的生成方式(均为一次仅能生成对应一个应用市场的安装包),一种是通过ide来生成,另一种是通过命令来生成。ide生成方式首先需要在配置文件中build.gradle中的flavor标识区域内设置好应用的渠道信息(或其他自定义属性,现以渠道为例),所述渠道是指投放的应用商店;然后在ide的生成安装包的引导窗口中填写好应用签名密钥的密码、名称、有效期、版权信息用以对应用进行签名,设定好后还要选定具体的flavor来生成某一特定渠道的安装包。而命令生成方式同样需要设置好配置文件,同时需要将签名相关信息也写到配置文件中,然后通过gradle提供的命令格式,将所需的各个flavor值按顺序填写到命令中,执行命令即可生成对应的渠道安装包。

现有技术方案一次仅能生成一个对应的渠道安装包,而国内的应用商店众多(多达20个以上),每个商店都需要上传对应的渠道安装包,用现有方式就需要,每生成一次安装包就要手动修改一次配置,再进行新一轮的生成,这样就存在众多重复操作,而且不能脱离人来自动完成,效率比较低且耗时较长。国内的android手机用户主要是从各大应用商店下载android应用,因此各个应用的发行公司需要将应用上传到商店并统计各个商店的应用下载量,因此就需要对应用做标识来进行统计,做了标识的应用即为渠道安装包;由于国内应用商店众多,每一次发布应用所需要生成的渠道安装包也会很多,利用现有的技术来生成,效率极低且耗费人力、时间,本发明提出了一种高效且实际验证可行的渠道包批量生成方法。

基于上述问题,本发明提供了一种android多自定义属性安装包自动生成方法,如图1所示,包括如下步骤:

s1、填写自定义属性列表文件;

s2、设置多自定义属性自动打包脚本的android应用程序工程代码的源文件路径和生成的安装包的保存路径;

s3、将自定义属性列表文件和多自定义属性自动打包脚本放置于同一目录;

s4、运行所述多自定义属性自动打包脚本;

s5、生成与所述自定义属性列表文件中多个自定义属性一一对应的安装包并存储于步骤s2中设置的保存路径;

s6、对工程代码进行清理;

s7、删除运行所述多自定义属性自动打包脚本过程中生成的备份文件。

通过上述方法,能够自动生成多个按需求定制的安装包。所述按需求定制体现为将自定义属性名称及其相应配置写入列表文件;所述自定义属性包括渠道标识、版本号和区分release和/或debug的标识、正式或测试服务器标识和业务类型标识等;所述release是指对外发布或投放到应用商店的app版本,有签名、加密的保护机制,运行时不会产生调试日志;正式发布到应用商店的app安装包一定是release的,但release的安装包不一定会发布到应用商店;所述debug指用于开发调试的app版本,不具有保护机制,且运行时会产生调试日志;所述业务类型标识,主要适用于同一份工程代码生成处理不同业务内容的app安装包,如具有做题、听课功能、公务员考试、教师招聘、司法考试、会计等业务内容不同的app,那么可以为不同业务生成功能相同但展现内容不同的app。所述自定义属性列表文件是一类属性一个列表,比如渠道属性,那么相应列表文件(channel.txt)里只有xiaomi、huawei、oppo、vivo、samsung等;比如连接服务器属性,那么相应列表文件(server.txt)里只有:developdevelop.xxx.com(地址)80(端口号)、onlineonline.xxx.com(地址)90(端口号)等;这样打包脚本可根据不同属性列表文件判断替换哪个属性及相应配置。

所述多自定义属性表示自定义属性选择确定后,在属性列表中输入该属性的不同属性名称,如将自定义属性选择为渠道,则多渠道表示多个不同的渠道名称(不同的应用商店),如将自定义属性选择为服务器,则多服务器表示可为正式的、测试的、北京的、广州的、上海的……等等多个不同的服务器。

所述步骤s1具体为:将各个自定义属性名称及其相应配置写入所述自定义属性列表文件中,每个自定义属性名称及其相应配置占一行,中间以空格隔开,以换行符作为每个自定义属性名称及其相应配置结束的标识。所述步骤s4的运行过程中包括输入所述标识作为参数。

所述步骤s4中运行所述多自定义属性自动打包脚本包括如下步骤,如图2所示:

s41、创建保存生成的安装包的文件目录;

s42、对工程代码执行清理和同步;

s43、从自定义属性列表文件中按顺序读取一个自定义属性名称及其相应配置;

s44、对工程代码中原有的自定义属性名称及其相应配置进行备份,并将步骤s43读取的自定义属性名称及其相应配置替换原有的自定义属性名称及其相应配置;

s45、根据输入的参数生成对应自定义属性名称的打包命令,并执行所述打包命令;

s46、生成的单个安装包存储到默认位置;

s47、将所述生成的单个安装包自动拷贝到的所述步骤s2的保存路径中;

s48、从步骤s44的备份文件中恢复工程代码的原有的自定义属性名称及其相应配置;

s49、返回步骤s43读取下一个自定义属性名称及其相应配置,直至所有的自定义属性名称及其相应配置读取完成以及所有对应安装包生成完毕。

所述步骤s41中根据输入的版本号参数,创建名为版本号的文件目录以保存所述生成的安装包。目录命名为版本号是因为发布、更新应用都是以版本号为区分度的,每次都是处理一个版本号的应用。

所述步骤s42中的清理步骤用于原有生成文件的清理,防止无用生成文件干扰打包流程;所述同步步骤用于检查工程代码是否存在编译错误,若出错则终止打包流程。

所述步骤s44具体为:读取出一个自定义属性名称及相应配置后,定位到工程代码配置文件中标识所述自定义属性名称及相应配置的位置,将原有的标识默认自定义属性名称的配置代码复制到临时备份文件中,若临时备份文件不存在则需要先创建,然后将读出的自定义属性名称按规定的格式填写好并替换掉原有的自定义属性名称的配置代码。定位的方式主要根据配置文件中原始默认自定义属性名及相应默认配置所在的行数,任何自定义属性在原始配置文件中都会有默认名称及相应默认配置标识,有多类属性则有多份标识。所述替换是从不同类别的属性列表文件中先读取出某一类别的属性名和相应配置,再到工程代码配置文件中去替换该类别属性的默认属性名和相应配置。

所述步骤s7删除的备份文件为所述步骤s44执行过程中生成的所述临时备份文件。

所述步骤s45中,若无对应的输入参数,则参数为工程代码配置文件中各类自定义属性的默认参数。

所述步骤s44中备份的是一个属性名及其相应配置,比如渠道(所投放的应用商店标识)属性就包括:渠道号、渠道上报名称等配置项;再比如业务类型标识属性就包括:appid、所接入的第三方服务密钥等配置项;连接服务器属性包括服务器地址、端口号等配置项。替换的也是属性名及其相应配置一并进行替换。

所述s46和s47两个步骤中安装包存储于默认位置后还需要拷贝到指定的保存路径,是因为google的打包程序无法定制生成的安装包存储位置,导致很多时候寻找安装包需要层层遍历文件目录,极不方便,因此将该打包脚本直接拷贝生成的安装包到方便查找的存储位置。

下面以渠道标识为例作为自定义属性,版本号和release或debug的区分等均不做定制(即取固定参数),对本发明的方法进行进一步说明。

本发明提供的一种android多渠道安装包自动生成方法,包括如下步骤:

1、将各个渠道的渠道名称、渠道号、渠道上报名称写到名为channel.txt的渠道列表文件中,每个渠道占一行,渠道名称、渠道号、渠道上报名称之间用空格隔开,以换行符作为每个渠道结束的标识。

2、设置多渠道自动化打包脚本的工程代码源文件根目录变量src_path的值和保存生成的安装包的目录变量dest_path的值。

3、将渠道列表文件和多渠道自动化打包脚本放在同一目录下,带上默认的版本号、release参数来运行自动化打包脚本,开始自动化打包流程,生成的安装包将保存在步骤2中dest_path路径下名为版本号的文件目录中。

4、渠道列表对应的所有安装包生成完毕后,对代码工程执行清理,防止生成安装包过程中产生的临时文件对代码工程造成影响;

5、删除运行多渠道自动化打包脚本过程中产生的临时备份文件。

以下为上述步骤3中多渠道自动化打包脚本的运行流程:

(1)根据输入的版本号参数,在指定路径下自动创建名为版本号的文件目录用以保存生成的安装包;

(2)自动进入工程代码的根目录(若自动化打包脚本在工程代码根目录下,则跳过这一步),执行代码工程原有生成文件的清理及同步(这两步具体的操作android官方已经嵌入在开发工具中,此处不再赘述,仅自动启动这两个流程;清理用于防止无用生成文件干扰打包流程,同步是为了检查工程代码是否存在编译错误,若出错则终止打包流程);

(3)开始从渠道列表按顺序读取渠道名;

(4)读取出一个渠道名后,定位到工程代码配置文件标识渠道的位置,在此处,首先将原有的标识默认渠道的配置代码整体复制到临时备份文件中(若不存在则需要先创建),然后将读出的渠道名按规定的格式填写好并整体替换掉原有的渠道配置代码;

(5)替换完成后,按照官方提供的生成单个安装包的命令格式,根据渠道名称及运行打包脚本时传入的参数来拼出相应的生成单个安装包的命令字符串,并执行该命令;

(6)命令执行完毕后,生成的单个应用安装包会存在于工程代码的默认生成目录中,脚本会自动将生成的安装包拷贝到步骤(1)中创建的名为版本号的文件目录中;

(7)将备份文件中的默认渠道配置代码,复制到工程代码配置文件的原位置,覆盖掉之前替换上去的内容,恢复为和原配置文件保持一致(每生成一个安装包就恢复一次配置,以防止在生成下一个渠道对应的安装包时出错);

(8)回到步骤(3)以读取下一个渠道名及相应配置,直至所有的渠道名及相应配置都读取完成并生成相应的安装包。

如上所述,按照多渠道进行定制的安装包自动生成的方法使得系统可以按照不同渠道全自动地完成安装包的打包生成,克服了现有的一次仅能生成一个对应的渠道安装包的问题,大大提高了工作效率。

本发明的另一方面提供了一种android多自定义属性安装包自动生成系统,包括:

存储器以及一个或多个处理器;

其中,所述存储器与所述一个或多个处理器通信连接,所述存储器中存储有可被所述一个或多个处理器执行的指令,所述指令被所述一个或多个处理器执行,以使所述一个或多个处理器用于执行前面所述的android多自定义属性安装包自动生成方法。

本发明的又一方面提供了一种计算机可读存储介质,其上存储有计算机可执行指令,当所述计算机可执行指令被计算装置执行时,可操作来执行前面所述的android多自定义属性安装包自动生成方法。

综上所述,本发明的一种android多自定义属性安装包自动生成方法,利用官方提供的单个安装包的命令行生成方式来进行全自动化生成多个按需求定制的安装包,将flavor标识的多自定义属性(包括多渠道、多连接服务器、多业务类型等)写入列表文件然后通过上述方法来生成定制化的安装包。所述方法在每次生成完一个执行文件后就进行原始配置文件的恢复,以防止干扰下一次打包流程,或因为后续流程出错中断,导致配置文件无法被恢复;而且每次只读取一个自定义属性列表并写入配置文件,该全自动化的流程代替人力完成了诸多需要手动修改的操作,大大提升了效率,且解放了人力。

术语解释:

ide:集成开发环境

渠道:即国内的各家android应用商店,也包括google官方的googleplay应用商店

渠道包:带有某个应用商店标识的android设备上的安装包

flavor:android应用的代码工程的配置文件build.gradle中的一个关键字,用来给应用添加不同的属性配置,如渠道、release与debug之分、正式与测试服务器之分等。

打包:即生成android安装包(安装到android设备的可执行文件)。

应当理解的是,本发明的上述具体实施方式仅仅用于示例性说明或解释本发明的原理,而不构成对本发明的限制。因此,在不偏离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。此外,本发明所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1