一种安卓应用升级方法、装置、设备及存储介质与流程

1.本技术实施例涉及安卓应用升级技术领域，尤其涉及一种安卓应用升级方法、装置、设备及存储介质。


背景技术：

2.目前，当需要升级一台安卓系统的交互式智能平板时，工程师需要在系统分支上进行编译打包，因为涉及到安卓原生系统的编译以及各个apk(android application package，安卓应用程序包)编译，整个过程需要大概2个小时左右，最终产生一个img格式的rom(read-only memory，只读存储器)包安装文件，大小约4gb。工程师将安装文件提供给售后人员进行上门u盘刷机安装或者通过后台系统进行ota下发到用户的交互智能平板进行在线下载升级。
3.发明人发现交互式智能平板的应用升级时，都需要对原生系统和所有apk进行编译，但每次的应用升级只是升级部分应用，对其他不用升级的应用进行编译属于做无用功，耗时长。对原始系统和所有apk进行编译生成的安装文件约4gb，不便于传输和存储，需要准备较大的闪存以及对用户网络条件要求较高。而且每次编译后都需要对整个安装文件进行全量测试，测试时间长达三天，消耗过多的人力资源，且交付周期过长。售后人员在通过u盘进行上门刷机时，升级耗时较长，售后人员工作效率低，而ota联网升级下载耗时长，用户需等待较长的下载和安装时间，用户体验较差。


技术实现要素：

4.本技术实施例提供一种安卓应用升级方法、装置、设备及存储介质，解决了应用程序升级效率低的问题，提高了用户使用体验。
5.在第一方面，本技术实施例提供了一种安卓应用升级方法，包括：
6.在对升级应用进行编译打包前，确认安卓操作系统的更新状态；
7.若所述安卓操作系统没有更新，则对所述升级应用进行编译打包，得到对应的安卓应用程序包；
8.将所述升级应用的安卓应用程序包存储至代码仓库，将所述升级应用的安卓应用程序包的信息存储至所述代码仓库的配置文件中；
9.从所述配置文件中读取所有安卓应用程序包的信息，根据所述所有安卓应用程序包的信息生成应用配置文件；
10.根据所述应用配置文件生成应用安装文件，并将所述应用安装文件复制至客户端，以使所述客户端根据所述应用安装文件对本地待升级应用进行升级。
11.在第二方面，本技术实施例提供了一种安卓应用升级方法，包括：
12.获取应用安装文件，从所述应用安装文件中提取应用配置文件，所述应用配置文件包括安卓应用程序包的版本信息和地址信息；
13.根据所述版本信息和本地安装应用的版本信息，确认本地待升级应用，并根据所
述待升级应用对应的地址信息，从代码仓库中下载对应的安卓应用程序包；
14.在所有待升级应用的安卓应用程序包下载完成后，安装所述安卓应用程序包。
15.在第三方面，本技术实施例提供了一种安卓应用升级装置，包括：
16.状态确认模块，被配置为在对升级应用进行编译打包前，确认安卓操作系统的更新状态；
17.编译模块，被配置为若所述安卓操作系统没有更新，则对所述升级应用进行编译打包，得到对应的安卓应用程序包；
18.安装包存储模块，被配置为将所述升级应用的安卓应用程序包存储至代码仓库，将所述升级应用的安卓应用程序包的信息存储至所述代码仓库的配置文件中；
19.配置文件生成模块，被配置为从所述配置文件中读取所有安卓应用程序包的信息，根据所述所有安卓应用程序包的信息生成应用配置文件；
20.安装文件复制模块，被配置为根据所述应用配置文件生成应用安装文件，并将所述应用安装文件复制至客户端，以使所述客户端根据所述应用安装文件对本地待升级应用进行升级。
21.在第四方面，本技术实施例提供了一种安卓应用升级装置，包括：
22.配置文件获取模块，被配置为获取应用安装文件，从所述应用安装文件中提取应用配置文件，所述应用配置文件包括安卓应用程序包的版本信息和地址信息；
23.安装包下载模块，被配置为根据所述版本信息和本地安装应用的版本信息，确认本地待升级应用，并根据所述待升级应用对应的地址信息，从代码仓库中下载对应的安卓应用程序包；
24.安装模块，被配置为在所有待升级应用的安卓应用程序包下载完成后，安装所述安卓应用程序包。
25.在第五方面，本技术实施例提供了一种电子设备，包括：
26.存储器以及一个或多个处理器；
27.所述存储器，用于存储一个或多个程序；
28.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面和第二方面任一项所述的安卓应用升级方法。
29.在第六方面，本技术实施例提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如第一方面和第二方面任一项所述的安卓应用升级方法。
30.本技术实施例通过将应用层的应用与系统层的操作系统解耦，对于本次应用升级未涉及修改的操作系统以及部分应用无需进行编译，仅针对本次升级有修改的应用进行编译打包，大大缩短了编译时间。同时应用安装文件中只有涉及升级修改的应用程序发生变化，而其他未涉及升级修改的应用程序还是沿用原来的应用程序，由于原来的应用程序已通过测试，因此仅需针对升级修改的应用程序做测试以及测试操作系统的基本功能，无需对操作系统进行全量测试，大大缩短了测试时间，节省了测试资源。除此之外，应用安装文件中包括的是安卓应用程序包的信息，其相比于安卓应用程序包所占内存更小，也更方便传输和存储，通过安卓应用程序包的信息代表安卓应用程序包进行传输和存储，在能达到升级目的的同时，还能提高传输效率，节约存储资源。客户端在进行ota升级时，只需下载有
升级修改的应用程序包，无需下载整个4gb的rom包安装文件，提高ota升级效率。客户端在进行u盘刷机安装时，由于应用安装文件较小，即使不同的机型对应不同的应用安装文件，也可以将所有机型的应用安装文件存储在同一个u盘中，由客户端自动拉取对应的应用安装文件，节约存储资源，客户端也无需拷贝整个4gb的rom包，提高升级效率。
附图说明
31.图1是本技术实施例一提供的一种用于服务端的安卓应用升级方法的流程图；
32.图2是应用安装文件的一种可选的具体复制流程图；
33.图3是本技术实施例一提供的一种用于客户端的安卓应用升级方法的流程图；
34.图4是应用安装文件的一种可选的具体获取流程图；
35.图5是安卓应用程序包的一种可选的具体安装流程图；
36.图6是本技术实施例二提供的一种用于服务端的安卓应用升级装置的结构示意图；
37.图7是本技术实施例二提供的一种用于客户端的安卓应用升级装置的结构示意图；
38.图8是本技术实施例三提供的一种电子设备的结构示意图。
具体实施方式
39.为了使本技术的目的、技术方案和优点更加清楚，下面结合附图对本技术具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本技术，而非对本技术的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本技术相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。
40.本技术实施例提供的安卓应用升级方法、装置、设备及存储介质，旨在通过在对升级应用进行编译打包前，确认安卓操作系统的更新状态；若安卓操作系统没有更新，则对升级应用进行编译打包，得到对应的安卓应用程序包；将升级应用的安卓应用程序包存储至代码仓库，将升级应用的安卓应用程序包的信息存储至代码仓库的配置文件中；从配置文件中读取所有安卓应用程序包的信息，根据所有安卓应用程序包的信息生成应用配置文件；根据应用配置文件生成应用安装文件，并将应用安装文件复制至客户端，以使客户端根据应用安装文件对本地待升级应用进行升级。相对于传统的安卓应用升级方法，其在进行安卓应用升级时，是都需要对原生系统和所有apk进行编译，但每次的应用升级只是升级部分应用，对其他不用升级的应用进行编译属于做无用功，耗时长。对原始系统和所有apk进行编译生成的安装文件约4gb，不便于传输和存储，需要准备较大的闪存以及对用户网络条件要求较高。而且每次编译后都需要对整个安装文件进行全量测试，测试时间长达三天，消耗过多的人力资源，且交付周期过长。售后人员在通过u盘进行上门刷机时，升级耗时较长，售后人员工作效率低，而ota联网升级下载耗时长，用户需等待较长的下载和安装时间，用
户体验较差。基于此，本技术实施例提出一种安卓应用升级方法、装置、设备及存储介质，以解决应用程序升级效率低的问题。
41.实施例一：
42.图1是本技术实施例一提供的一种用于服务端的安卓应用升级方法的流程图。实施例中提供的安卓应用升级方法可以基于安卓应用升级设备执行，该安卓应用升级设备可以通过软件和/或硬件的方式实现，该安卓应用升级设备可以是两个或多个物理实体构成，也可以是一个物理实体构成。例如，安卓应用升级设备可以是服务器。
43.为了便于理解，实施例中以服务器为安卓应用升级设备进行示例性描述。
44.具体的，参考图1，本技术实施例提供的安卓应用升级方法包括：
45.s101、在对升级应用进行编译打包前，确认安卓操作系统的更新状态。
46.s102、若安卓操作系统没有更新，则对升级应用进行编译打包，得到对应的安卓应用程序包。
47.具体的，传统的安卓应用升级方法在应用升级时对系统层的操作系统和应用层的所有应用程序进行编译打包，但其实在很多时候操作系统并没有更新，即不需要对操作系统进行编译。因此本技术实施例在每次需要编译应用新版本时，会先判断操作系统是否有更新，如果操作系统没有更新，则对升级应用进行编译打包。
48.可理解的，一个安卓应用程序的代码想要在安卓客户端上运行，需要先进行编译，然后被打包成一个能被安卓操作系统识别的文件，而能被安卓操作系统识别并运行的文件格式便是apk(android application package，安卓应用程序包)。当安卓应用程序更新到新版本时，对新版本的安卓应用程序进行编译打包，得到新版本的安卓应用程序包，即得到升级应用的安卓应用程序包，对于其他没有更新的安卓应用程序，由于其程序没有发生变化，因此继续使用原来的安卓应用程序包。
49.s103、将升级应用的安卓应用程序包存储至代码仓库，将升级应用的安卓应用程序包的信息存储至代码仓库的配置文件中。
50.具体的，将新版本的安卓应用程序包存储至代码仓库中，替换旧版本的安卓应用程序包，将新版本的安卓应用程序包的信息存储至代码仓库的配置文件中，替换旧版本的信息。其中，代码仓库通过artifactory进行搭建，artifactory是一种仓库服务端软件，可以用来在内网搭建代码仓库，供内部公共库的上传和发布，以提高公共代码使用的便利性。代码仓库的配置文件为config.xml，config.xml是应用的配置文件，用于指定应用的显示名称、图标、应用起始页地址及需要使用的设备权限等信息，可通过可视化界面或源码视图在config.xml中配置应用的相关信息。为实现客户端根据安卓应用程序安装包的版本确认待升级应用以及从代码仓库中下载待升级应用对应的安卓应用程序安装包，将安卓应用程序安装包的版本信息和地址信息存储至config.xml中。可理解的，当客户端需要下载安卓应用程序包时，只需要根据安卓应用程序包的版本信息确认需要待升级应用，以及根据待升级应用的地址信息，即可从代码仓库中下载对应的安卓应用程序包，升级过程简单快捷。
51.s104、从配置文件中读取所有安卓应用程序包的信息，根据所有安卓应用程序包的信息生成应用配置文件。
52.具体的，从config.xml中读取所有安卓应用程序包的信息，并根据所有安卓应用程序包的信息生成文件格式为json(javascript object notation)的应用配置文件。json
是一种轻量级的数据交换格式，其采用完全独立于编程语言的文本格式来存储和表示数据，通过json实现服务端和客户端的信息交流，容易进行编写和阅读，同时也便于客户端对应用配置文件的解析和服务端生成应用配置文件，有效地提高升级效率。
53.需要说明的是，有些客户端上安装的应用可能已经很久没有进行版本更新，但这些应用在本次新版本编译时又没有更新，那为了满足客户端上所有应用升级的要求，将所有安卓应用程序包的信息生成应用配置文件，那么客户端根据应用配置文件中的信息不仅可以更新本次编译的升级应用，还可以更新其他版本落后的应用。
54.s105、根据应用配置文件生成应用安装文件，并将应用安装文件复制至客户端，以使客户端根据应用安装文件对本地待升级应用进行升级。
55.具体的，将应用配置文件和预设的安装前置脚本以及安装后置脚本结合，生成一个客户端的系统升级软件可识别和可执行的应用安装文件，系统升级软件会执行安装前置脚本、执行安卓应用程序包安装以及安装后置脚本，直至这个升级完成。由于本技术实施例中只需要升级应用层的应用，而无需对操作系统进行升级，因此无需将整个操作系统进行打包生成安装文件，在脱离了操作系统的整包升级后，基于应用的安卓应用程序包的版本信息和其他属性信息的特性，可实现对应用的差分升级，提高升级效率以及传输效率，还节约存储资源。
56.进一步的，参考图2，图2是应用安装文件的一种可选的具体复制流程图。如图2所示，应用安装文件的复制流程包括：
57.s1051、对应用安装文件进行测试；
58.s1052、若应用安装文件通过测试，则将应用安装文件上传至后台服务系统，由后台服务系统向客户端发送应用安装文件；或，
59.s1053、将应用安装文件拷贝至移动闪存盘，由客户端从对应的移动闪存盘读取应用安装文件。
60.示例性的，为检测应用安装文件是否能达到预期效果，通过移动闪存盘安装升级方式对其进行测试，若测试达到预期效果，则表明可通过应用安装文件对客户端的应用进行更新，即可将应用安装文件复制至客户端，由客户端的系统升级软件运行根据应用安装文件更新本地待升级应用。需要说明的是，可能客户端中有些应用在之前的版本更新时没有进行相应的更新升级，那么在此次应用升级中，即使有些应用没有新编译的版本，但其相对于代码仓库中的安卓应用程序包的版本还是落后的，因此客户端的待升级应用是指本地安装的安卓应用程序包的版本落后于代码仓库中的安卓应用程序包的版本的应用。而服务端的升级应用是指本次应用升级中新编译安卓应用程序包的应用，可理解的，客户端的待升级应用包括升级应用以及以往没有进行相应更新的应用。
61.进一步的，将应用安装文件复制客户端有两种具体的实现方式，第一种实现方式为：将所有机型的应用安装文件上传至后台服务系统，由客户端的系统升级软件根据客户端的机型拉取对应的应用安装文件，由于应用安装文件的内存相比于整包的安装文件要小得多，不管是服务端将应用安装文件上传至后台服务系统还是客户端从后台服务系统拉取应用安装文件，都缩短了传输时间，提高了ota升级效率。第二种实现方式为：将所有机型的应用安装文件拷贝至移动闪存盘，在移动闪存盘插入客户端后，由客户端的系统升级软件根据客户端的机型拉取对应的应用安装文件。由于应用安装文件的内存相比于整包的安装
文件要小得多，一个移动闪存盘即可存完所有机型的应用安装文件，大大节约了存储资源。
62.另一方面，为保证客户端能够基于服务端生成的应用安装文件，对本地待升级应用进行更新处理，针对上述在服务端上运行的安卓应用升级方法，提出一种运行在客户端上的安卓应用升级方法，与服务端上运行的安卓应用升级方法相对应。
63.图3是本技术实施例一提供的一种用于客户端的安卓应用升级方法的流程图。实施例中提供的安卓应用升级方法可以基于安卓应用升级设备执行，该安卓应用升级设备可以通过软件和/或硬件的方式实现，该安卓应用升级设备可以是两个或多个物理实体构成，也可以是一个物理实体构成。例如，安卓应用升级设备可以是会议平板。
64.为了便于理解，实施例中以会议平板为安卓应用升级设备进行示例性描述。
65.具体的，参考图3，本技术实施例提供的安卓应用升级方法包括：
66.s201、获取应用安装文件，从应用安装文件中提取应用配置文件，应用配置文件包括安卓应用程序包的版本信息和地址信息。
67.具体的，参考图4，图4是应用安装文件的一种可选的具体获取流程图。如图4所示，应用安装文件的获取流程包括：
68.s2011、将本地配置的机型信息和后台服务系统中所有应用安装文件的客户端机型信息进行匹配，从后台服务系统拉取对应的应用安装文件；
69.s2012、将本地配置的机型信息和移动闪存盘中所有应用安装文件的客户端机型信息进行匹配，从移动闪存盘中读取对应的应用安装文件。
70.示例性的，由于不同的客户端对应不同的机型，不用的机型对应不同的应用安装文件，因此系统升级软件将本地配置的机型信息与应用安装文件配置的机型信息进行匹配，确认合适的应用安装文件。如果存有应用安装文件的移动闪存盘插入客户端中，系统升级软件检测到应用安装文件的机型信息，读取合适兼容的应用安装文件。如果客户端没有插有移动闪存盘，系统升级软件可以联网检测到后台服务系统有应用升级信息，即检测到后台服务系统接收到服务端发送新的应用安装文件，系统升级软件从后台服务系统拉取对应的应用安装文件。
71.s202、根据版本信息和本地安装应用的版本信息，确认本地待升级应用，并根据待升级应用对应的地址信息，从代码仓库中下载对应的安卓应用程序包。
72.具体的，提取应用安装文件中的应用配置文件，将应用配置文件中的安卓应用程序包的版本与本地安装应用的版本进行比较。若应用配置文件中的版本与本地安装应用的版本一致，则表明此次新版本编译时该应用没有升级，本地安装的安卓应用程序包和代码仓库中的安卓应用程序包一致，无需下载该应用的安卓应用程序包。若应用配置文件中的版本高于本地安装应用的版本，则表明此次新版本编译时该应用升级到新版本，代码仓库中的安卓应用程序包的版本高于本地安装的安卓应用程序包的版本，因此需要根据应用配置文件中对应的地址信息从代码仓库中下载最新版本的安卓应用程序包。
73.s203、在所有待升级应用的安卓应用程序包下载完成后，安装安卓应用程序包。
74.具体的，参考图5，图5是安卓应用程序包的一种可选的具体安装流程图。如图5所示，安卓应用程序包的安装流程包括：
75.s2031、接收确认升级指令，根据确认升级指令确认被选中的待升级应用；
76.s2032、安装被选中的待升级应用对应的安卓应用程序包。
77.示例性的，在所有待升级应用的安卓应用程序包下载完成后，系统升级软件在客户端的显示屏上弹出一个升级提示框，用于显示本次应用升级可以升级哪些应用，即显示待升级应用。用户可通过升级提示框选择想要升级的应用，根据用户输入的操作生成确认升级指令，确认升级指令包括用户选中的待升级应用。系统升级软件根据确认升级指令确认被选中的待升级应用，安装前置脚本、安装被选中的待升级应用以及安装后置脚本，以完成本次应用升级。
78.综上，本技术实施例通过将应用层的应用与系统层的操作系统解耦，对于本次应用升级未涉及修改的操作系统以及部分应用无需进行编译，仅针对本次升级有修改的应用进行编译打包，大大缩短了编译时间。同时应用安装文件中只有涉及升级修改的应用程序发生变化，而其他未涉及升级修改的应用程序还是沿用原来的应用程序，由于原来的应用程序已通过测试，因此仅需针对升级修改的应用程序做测试以及测试操作系统的基本功能，无需对操作系统进行全量测试，大大缩短了测试时间，节省了测试资源。除此之外，应用安装文件中包括的是安卓应用程序包的信息，其相比于安卓应用程序包所占内存更小，也更方便传输和存储，通过安卓应用程序包的信息代表安卓应用程序包进行传输和存储，在能达到升级目的的同时，还能提高传输效率，节约存储资源。客户端在进行ota升级时，只需下载有升级修改的应用程序包，无需下载整个4gb的rom包安装文件，提高ota升级效率。客户端在进行u盘刷机安装时，由于应用安装文件较小，即使不同的机型对应不同的应用安装文件，也可以将所有机型的应用安装文件存储在同一个u盘中，由客户端自动拉取对应的应用安装文件，节约存储资源，客户端也无需拷贝整个4gb的rom包，提高升级效率。
79.实施例二
80.图6是本技术实施例二提供的一种用于服务端的安卓应用升级装置的结构示意图。参考图6，该安卓应用升级装置包括：状态确认模块31、编译模块32、安装包存储模块33、配置文件生成模块34和安装文件复制模块35。
81.其中，状态确认模块31，被配置为在对升级应用进行编译打包前，确认安卓操作系统的更新状态；
82.编译模块32，被配置为若安卓操作系统没有更新，则对升级应用进行编译打包，得到对应的安卓应用程序包；
83.安装包存储模块33，被配置为将升级应用的安卓应用程序包存储至代码仓库，将升级应用的安卓应用程序包的信息存储至代码仓库的配置文件中；
84.配置文件生成模块34，被配置为从配置文件中读取所有安卓应用程序包的信息，根据所述所有安卓应用程序包的信息生成应用配置文件；
85.安装文件复制模块35，被配置为根据应用配置文件生成应用安装文件，并将应用安装文件复制至客户端，以使客户端根据应用安装文件对本地待升级应用进行升级。
86.在上述实施例的基础上，安卓应用升级装置还包括：测试模块，被配置为对应用安装文件进行测试，若应用安装文件通过测试则将应用安装文件复制至客户端。
87.在上述实施例的基础上，安装文件复制模块包括：上传单元，被配置为将应用安装文件上传至后台服务系统，由后台服务系统向客户端发送应用安装文件；或,拷贝单元，被配置为将应用安装文件拷贝至移动闪存盘，由客户端从对应的移动闪存盘读取应用安装文件。
88.图7是本技术实施例二提供的一种用于客户端的安卓应用升级装置的结构示意图。参考图7，该安卓应用升级装置包括：配置文件获取模块41、安装包下载模块42和安装模块43。
89.其中，配置文件获取模块41，被配置为获取应用安装文件，从应用安装文件中提取应用配置文件，应用配置文件包括安卓应用程序包的版本信息和地址信息；
90.安装包下载模块42，被配置为根据版本信息和本地安装应用的版本信息，确认本地待升级应用，并根据待升级应用对应的地址信息，从代码仓库中下载对应的安卓应用程序包；
91.安装模块43，被配置为在所有待升级应用的安卓应用程序包下载完成后，安装安卓应用程序包。
92.在上述实施例的基础上，配置文件获取模块包括拉取单元，被配置为将本地配置的机型信息和后台服务系统中所有应用安装文件的客户端机型信息进行匹配，从后台服务系统拉取对应的应用安装文件；或，读取单元，被配置为将本地配置的机型信息和移动闪存盘中所有应用安装文件的客户端机型信息进行匹配，从移动闪存盘中读取对应的应用安装文件。
93.在上述实施例的基础上，安装模块包括应用确认单元，被配置为接收确认升级指令，根据确认升级指令确认被选中的待升级应用；应用升级单元，被配置为安装被选中的待升级应用对应的安卓应用程序包。
94.上述，通过将应用层的应用与系统层的操作系统解耦，对于本次升级未涉及修改的操作系统以及部分应用无需进行编译，仅针对本次升级有修改的应用进行编译打包，大大缩短了编译时间。同时应用安装文件中只有涉及升级修改的应用程序发生变化，而其他未涉及升级修改的应用程序还是沿用原来的应用程序，由于原来的应用程序已通过测试，因此仅需针对升级修改的应用程序做测试以及测试操作系统的基本功能，无需对操作系统进行全量测试，大大缩短了测试时间，节省了测试资源。除此之外，应用安装文件中包括的是安卓应用程序包的信息，其相比于安卓应用程序包所占内存更小，也更方便传输和存储，通过安卓应用程序包的信息代表安卓应用程序包进行传输和存储，在能达到升级目的的同时，还能提高传输效率，节约存储资源。客户端在进行ota升级时，只需下载有升级修改的应用程序包，无需下载整个4gb的rom包安装文件，提高ota升级效率。客户端在进行u盘刷机安装时，由于应用安装文件较小，即使不同的机型对应不同的应用安装文件，也可以将所有机型的应用安装文件存储在同一个u盘中，由客户端自动拉取对应的应用安装文件，节约存储资源，客户端也无需拷贝整个4gb的rom包，提高升级效率。
95.本技术实施例提供的安卓应用升级装置包含在安卓应用升级设备中，且可用于执行上述任意实施例提供的安卓应用升级方法，具备相应的功能和有益效果。
96.实施例三
97.图8是本技术实施例三提供的一种电子设备的结构示意图。如图8所示，该电子设备包括处理器50、存储器51、输入装置52、输出装置53以及显示屏54；电子设备中处理器50的数量可以是一个或多个，图8中以一个处理器50为例；电子设备中显示屏54的数量可以是一个或多个，图8中以一个显示屏54为例；电子设备中的处理器50、存储器51、输入装置52、输出装置53以及显示屏54可以通过总线或其他方式连接，图8中以通过总线连接为例。
98.存储器51作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本技术实施例中的安卓应用升级方法对应的程序指令/模块(例如，安卓应用升级装置中的状态确认模块31、编译模块32、安装包存储模块33、配置文件生成模块34、安装文件复制模块35或配置文件获取模块41、安装包下载模块42和安装模块43)。处理器50通过运行存储在存储器51中的软件程序、指令以及模块，从而执行电子设备的各种功能应用以及数据处理，即实现上述安卓应用升级方法。
99.存储器51可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据电子设备的使用所创建的数据等。此外，存储器51可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器51可进一步包括相对于处理器50远程设置的存储器，这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
100.输入装置52可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。输出装置53可包括扬声器等音频输出设备。显示屏54为具有触摸功能的显示屏，其可以是电容屏、电磁屏或者红外屏。可选的，当显示屏54为红外屏时，其还包括红外触摸框，该红外触摸框设置在显示屏54的四周，其还可以用于接收红外信号，并将该红外信号发送至处理器50或者其他设备。显示屏54可以根据处理器的指令显示其他的内容。
101.上述电子设备包含安卓应用升级装置，可以用于执行任意安卓应用升级方法，具备相应的功能和有益效果。
102.实施例四
103.本技术实施例提供一种用于服务端的包含计算机可执行指令的存储介质，计算机可执行指令在由计算机处理器执行时用于执行如上述实施例一提供的安卓应用升级方法，该方法包括：
104.在对升级应用进行编译打包前，确认安卓操作系统的更新状态；
105.若安卓操作系统没有更新，则对升级应用进行编译打包，得到对应的安卓应用程序包；
106.将升级应用的安卓应用程序包存储至代码仓库，将升级应用的安卓应用程序包的信息存储至代码仓库的配置文件中；
107.从配置文件中读取所有安卓应用程序包的信息，根据所述所有安卓应用程序包的信息生成应用配置文件；
108.根据应用配置文件生成应用安装文件，并将应用安装文件复制至客户端，以使客户端根据应用安装文件对本地待升级应用进行升级。
109.本技术实施例还提供一种用于客户端的包含计算机可执行指令的存储介质，计算机可执行指令在由计算机处理器执行时用于执行如上述实施例一提供的安卓应用升级方法，该方法包括：
110.获取应用安装文件，从应用安装文件中提取应用配置文件，应用配置文件包括安卓应用程序包的版本信息和地址信息；
111.根据版本信息和本地安装应用的版本信息，确认本地待升级应用，并根据待升级
应用对应的地址信息，从代码仓库中下载对应的安卓应用程序包；
112.在所有待升级应用的安卓应用程序包下载完成后，安装安卓应用程序包。
113.当然,本技术实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的方法操作,还可以执行本技术任意实施例所提供的安卓应用升级方法中的相关操作。
114.通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本技术可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(read-only memory,rom)、随机存取存储器(random access memory,ram)、闪存(flash)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例的方法。
115.值得注意的是，上述基于安卓应用升级装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。
116.注意，上述仅为本技术的较佳实施例及所运用技术原理。本领域技术人员会理解，本技术不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本技术的保护范围。因此，虽然通过以上实施例对本技术进行了较为详细的说明，但是本技术不仅仅限于以上实施例，在不脱离本技术构思的情况下，还可以包括更多其他等效实施例，而本技术的范围由所附的权利要求范围决定。