固件升级文件处理方法、装置、服务器及存储介质与流程

1.本技术属于电子技术领域，尤其涉及一种固件升级文件处理方法、装置、服务器及存储介质。


背景技术：

2.随着空中升级(over the air，ota)技术的发展，各类终端的固件升级越来越方便。终端在基于ota技术升级时，往往会从服务器下载的固件升级包。
3.相关技术中，固件升级包中的系统参数(例如系统目录镜像)，可能与终端的刷机包(例如bin文件)的系统参数不一致，进而导致终端固件升级失败。


技术实现要素：

4.本技术实施例提供一种固件升级文件处理方法、装置、服务器及存储介质，以解决因固件升级包的系数参数与终端的刷机包的系统参数不一致，导致终端固件升级失败的问题。
5.第一方面，本技术实施例提供一种固件升级文件处理方法，方法包括：
6.获取配置文件；
7.读取配置文件中的预设条目，生成与预设条目对应的条目镜像；
8.编译配置文件，生成中间包，中间包包括基于条目镜像生成的内核符号表；
9.打包中间包，得到固件升级包。
10.第二方面，本技术实施例提供了一种固件升级文件处理装置，装置包括：
11.第一获取模块，用于获取配置文件；
12.读取生成模块，用于读取配置文件中的预设条目，生成与预设条目对应的条目镜像；
13.编译模块，用于编译配置文件，生成中间包，中间包包括基于条目镜像生成的内核符号表；
14.打包模块，用于打包中间包，得到固件升级包。
15.第三方面，本技术实施例提供了一种服务器，服务器包括：处理器以及存储有计算机程序指令的存储器；
16.处理器执行计算机程序指令时实现第一方面所示的固件升级文件处理方法。
17.第四方面，本技术实施例提供了一种计算机存储介质，计算机存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现第一方面所示的固件升级文件处理方法。
18.第五方面，本技术实施例提供了一种计算机程序产品，计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备执行第一方面所示的固件升级文件处理方法。
19.本技术实施例提供的固件升级文件处理方法，获取配置文件，读取配置文件中的预设条目，生成与预设条目对应的条目镜像，编译配置文件，生成中间包，该中间包包括基
于条目镜像生成的内核符号表，打包中间包，得到固件升级包。本技术实施例中，通过读取配置文件，生成预设条目对应的条目镜像文件，并基于镜像文件生成内核符号表，可以避免编译得到的中间包中预设条目等发生改变，进而有助于保证固件升级包与待升级的终端固件在预设条目上保持一致，提高终端固件升级成功率。
附图说明
20.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
21.图1是实现本技术实施例的固件升级文件处理方法的框架的示例图；
22.图2是本技术实施例提供的固件升级文件处理方法的流程示意图；
23.图3是固件录入模块及相关模块的工作原理示意图；
24.图4是固件管理模块的工作原理示意图；
25.图5是大屏升级模块及相关模块的工作原理示意图；
26.图6是版本升级查询模块的工作原理示意图；；
27.图7是固件差分版本计算模块及相关模块的工作原理示意图；
28.图8是本技术中固件升级文件处理方法与常规技术中安卓系统差分升级过程的对比图；
29.图9是本技术实施例提供的固件升级文件处理装置的结构示意图；
30.图10是本技术实施例提供的服务器的结构示意图。
具体实施方式
31.下面将详细描述本技术的各个方面的特征和示例性实施例，为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本技术进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本技术，而不是限定本技术。对于本领域技术人员来说，本技术可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本技术的示例来提供对本技术更好的理解。
32.需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
33.为了解决现有技术问题，本技术实施例提供了一种固件升级文件处理方法、装置、服务器及存储介质。下面首先对可应用本技术实施例所提供的固件升级文件处理方法的框架进行介绍。
34.如图1所示，该框架可以包括服务器110与终端120，服务器110与终端120之间通讯连接，服务器110可以生成或录入用于终端固件升级的固件升级包，并可以基于ota技术将
固件升级包发送至终端120。其中，终端120可以是例如移动终端、大屏显示装置、个人电脑或者可穿戴设备等等，此处不作具体限定。
35.图2示出了本技术一个实施例提供的固件升级文件处理方法的流程示意图。如图2所示，该方法包括：
36.步骤201，获取配置文件；
37.步骤202，读取配置文件中的预设条目，生成与预设条目对应的条目镜像；
38.步骤203，编译配置文件，生成中间包，中间包包括基于条目镜像生成的内核符号表；
39.步骤204，打包中间包，得到固件升级包。
40.本技术实施例提供的固件升级文件处理方法，可以应用在服务器或者各类电子设备中，为简化说明，以下主要以固件升级文件处理方法应用在服务器中为例进行说明。
41.在一些示例中，步骤201中配置文件可以是指包括用于获得固件升级包的代码文件。比如，结合一些举例，配置文件可以包括用于镜像生成的build_image.py文件、用于ota打包的ota_from_target_files文件以及用于自动编译的makefile文件等等。
42.当然，以上是对配置文件的一些示例性说明，在实际应用中，配置文件还可以包括其他用于固件升级包生成的文件，此处不作一一举例。
43.步骤202中，服务器可以读取配置文件中的预设条目，这些预设条目可以是用于内核符号表生成的条目。
44.在一些示例中，内核符号表可以为system.map，为简化描述，以下主要以内核符号表为system.map为例进行说明。
45.发明人在研发中发现，相关技术中通常在获取到配置文件后，直接对配置文件进行编译，通过这种编译方式得到的system.map中，例如区块列表(block_list)与存储类型(fs_type)等条目发生了变化。
46.system.map可以用于镜像生成固件升级包中的系统目录镜像(system.img)，即固件升级包中的system.img是与system.map对应的。在system.img中的一些条目发生变化的情况下，可能导致固件升级包中的system.img，与待进行固件升级的终端中的bin文件的system.img不同，进而导致终端固件升级失败。
47.本实施例中，预设条目还可以指：按照相关技术中的编译方式对配置文件进行编译(即直接对配置文件进行编译)的过程中，可能发生变化的条目。服务器可以预先读取这些预设条目，并生成与预设条目对应的条目镜像。
48.在一些举例中，可以通过修改上述build_image.py文件中的代码，使得在代码在被读取的情况下，服务器能够执行上述条目镜像生成的步骤。
49.步骤203中，服务器可以编译配置文件，生成中间包，该中间包可以包括基于上述条目镜像生成的system.map。
50.一般来说，system.map可以在编译内核时生成，其可以用于记录内核中的符号(例如函数、全局变量等)列表以及符号在内存中的虚拟位置等信息。
51.编译内核生成system.map的实现，可以通过现有技术来实现。而本实施例中，服务器可以在生成system.map的过程中，使用条目镜像。
52.具体来说，基于现有技术对配置文件进行编译时，配置文件中的预设条目可能会
发生变化，而本实施例中，可以在使得预设条目发生变化的编译阶段之后，将发生变化的预设条目替换为条目镜像。如此，在编译得到的中间包中，可以包括基于条目镜像生成的system.map。
53.步骤204中，服务器可以打包中间包，得到固件升级包。
54.结合一些应用场景，中间包可以是bin类型或者ota类型的中间包，此处不做具体限定。在生成中间包的基础上，服务器通常还需要对中间包进一步打包，得到例如zip或者其他类型的用于固件升级的固件升级包。
55.一般来说，在打包过程中，中间包的system.map可以纳入到固件升级包中，固件升级包中可以生成与system.map对应的system.img。
56.容易理解的是，实际应用中，在设置配置文件时，其中的预设条目通常可以与终端固件中预设条目保持一致。system.map是基于条目镜像生成的，避免了在编译过程中预设条目发生改变。相应地，由于system.img与system.map存在对应关系，因此，固件升级包中的预设条目也可以与终端固件中预设条目保持一致。如此，可以有效进一步保证固件升级包与终端固件中system.img一致，进而使得终端在接收到固件升级包的情况下，能够正常进行固件升级。
57.本步骤中得到的固件升级包可以是全量升级包、差分升级包或者兼而有之，此处不做具体限定。
58.本技术实施例提供的固件升级文件处理方法，获取配置文件，读取配置文件中的预设条目，生成与预设条目对应的条目镜像，编译配置文件，生成中间包，该中间包包括基于条目镜像生成的内核符号表，打包中间包，得到固件升级包。本技术实施例中，通过读取配置文件，生成预设条目对应的条目镜像文件，并基于镜像文件生成内核符号表，可以避免编译得到的中间包中预设条目等发生改变，进而有助于保证固件升级包与待升级的终端固件在预设条目上保持一致，提高终端固件升级成功率。
59.在一些实施方式中，上述的预设条目包括上述的block_list与fs_type，这两种预设条目在编译配置文件的过程中，有较大概率发生改变。本实施方式中，针对block_list与fs_type生成条目镜像，以便在生成内核符号表时，使用条目镜像替换掉大概率发生改变的预设条目，进而有助于保证后续得到的固件升级包与待升级的终端固件在预设条目上保持一致。
60.在一些实施方式中，通过设置ota_from_target_files文件，可以使得每次在打包中间包的过程中，均完整更新boot.img文件，一方面，可以节省boot.img文件的比对过程，另一方面，也可以有效避免因在打包阶段boot.img文件出现异常而导致终端固件升级失败的情况。
61.可选地，固件升级包包括第一全量升级包；
62.打包中间包，得到固件升级包之后，方法还包括：
63.接收第一终端发送的第一固件升级请求；
64.响应于第一固件升级请求，向第一终端发送第一全量升级包。
65.如上文实施例所示的，通过打包得到的固件升级包，可以是全量升级包或者差分升级包等。
66.本实施例中，第一全量升级包可以是固件升级包所包括的全量升级包。在一些应
用例中，服务器在对中间包进行打包时，可以固定生成第一全量升级包。
67.第一全量升级包通常包括固件版本升级时所需的完整数据，且该第一全量升级包可以供终端进行下载和安装。
68.一般来说，固件升级包与终端存在一定的对应关系。比如，对于移动终端与大屏显示装置，两者的固件升级包通常是存在差异的；对于不同型号的大屏显示装置，固件升级包也可能存在差异。
69.为便于说明，本实施例中，第一全量升级包可以与第一终端存在对应关系，也就是说，第一终端可以基于上述的第一全量升级包进行固件升级。
70.结合一些应用场景，第一终端可以查询服务器中是否存在可用于升级的固件升级包，当服务器存在可用于升级的固件升级包时，第一终端可以自动向服务器发送第一固件升级请求。或者，第一终端可以在接收到用户控制进行升级的预设操作时，向服务器发送第一固件升级请求。
71.如上文所示的，服务器打包中间包可以得到第一全量升级包，相应地，服务器在接收到第一终端发送的第一固件升级请求时，可以将第一全量升级包发送至第一终端。
72.当然，在实际应用中，服务器在接收到第一固件升级请求时，也可以是向第一终端发送第一全量升级包的下载地址，第一终端可以根据该下载地址，进一步下载第一全量升级包。
73.总的来说，第一终端可以基于与服务器的通信来获得第一全量升级包，从服务器的角度来说，可以认为服务器将第一全量升级包发送至第一终端。
74.本实施例中，固件升级包包括第一全量升级包，服务器在接收到第一终端发送的第一固件升级请求时，向第一终端发送第一全量升级包，有助于使得第一终端至少能够基于全量升级包实现固件的可靠升级。
75.可选地，固件升级包还包括差分基准包，第一固件升级请求携带有第一固件版本；
76.接收第一终端发送的第一固件升级请求之后，方法还包括：
77.获取与第一固件版本对应的第一固件文件；
78.依据差分基准包与第一固件文件生成第一差分升级包；
79.在接收到第二终端发送的携带有第一固件版本的第二固件升级请求的情况下，向第二终端发送第一差分升级包。
80.本实施例中，固件升级包可以包括第一全量升级包与差分基准包。第一全量升级包在上一实施例中进行了描述，此处不再赘述。
81.差分基准包可以是用于制作差分升级包的数据包。在一定程度上，差分基准包与第一全量升级包的内容可以是大致相似的，第一全量升级包可以直接发送至终端进行固件升级，而差分基准包则可以用于与历史版本的固件进行差分，得到差分升级包。
82.本实施例中，服务器在接收到第一终端发送的第一固件升级请求之后，除了可以将第一全量升级包发送至第一终端外，还可以根据第一终端的固件版本生成第一差分升级包。以下针对第一差分升级包的生成过程进行详细说明。
83.第一终端发送的第一固件升级请求可以携带有第一固件版本，第一固件版本可以是第一终端当前的固件的版本。
84.服务器在接收到第一固件版本之后，可以获取与第一固件版本对应的第一固件文
件。
85.在一些应用场景中，服务器中可以存储有各个固件版本对应的固件文件，这些固件文件可以是在历史固件升级包的制作过程中，生成的刷机包，或者生成的全量升级包等。
86.相应地，服务器在接收到第一固件版本的情况下，可以获取第一固件版本对应的固件文件，即上述的第一固件文件。
87.如上文所示的，第一差分基准包可以用于与历史版本的固件进行差分，而具体到本实施例中，服务器可以依据第一差分基准包与第一固件文件生成第一差分升级包。至于差分升级包的具体生成过程，可以通过现有技术来实现，此处不作赘述。
88.容易理解的是，在实际应用中，需要进行固件升级的终端的数量可能是多个，这些终端均可以向服务器发送携带有固件版本的固件升级请求。
89.结合一个应用场景，在服务器生成了固件升级包的情况下，会存在多个终端陆续向服务器发送固件升级请求。这些终端中可以包括第一终端与第二终端，第一终端与第二终端中当前的固件版本可以是相同的。
90.比如，各个固件版本可以通过版本号进行表示，服务器生成的固件升级包的版本号可以记为v3，而第一终端与第二终端的终端固件的版本号均为v1.1(对应第一固件版本)。
91.在服务器发布了v3版本的固件升级包的情况下，第一终端可能首先向服务器发送了第一固件升级请求，该第一固件升级请求携带有v1.1这一版本号。服务器响应于第一终端的第一固件升级请求，可以将v3版本的第一全量升级包发送至第一终端。
92.与此同时，从服务器的角度来说，在接收到携带有v1.1这一版本号的第一固件升级请求时，服务器可以获知当前存在v1.1固件版本的升级需求，为了节省后续v1.1固件版本的终端的固件下载流量，服务器可以进一步生成v1.1固件版本匹配的差分升级包(对应上述的第一差分升级包)。
93.第二终端可以在第一终端之后，向服务器发送携带有版本号v1.1的第二固件升级请求。而服务器在接收到第二终端发送的第二固件升级请求时，可能已经生成了v1.1固件版本对应的差分升级包，因此，可以将该差分升级包发送至第二终端。
94.在实际应用中，各个固件版本也可以通过固件版本的发布时间进行表示，相应地，在各个固件升级请求中携带的第一固件版本，可以是指第一固件版本的发布时间等。
95.总的来说，第一终端与第二终端可以是先后向服务器发送了携带有同一固件版本的固件升级请求。而本实施例中，服务器在接收到第一终端发送的第一固件升级请求的情况下，生成与第一固件版本匹配的第一差分升级包，以便服务器在再次接收到第二终端发送的携带有第一固件版本的第二固件升级请求的情况下，将所需下载流量较小的第一差分升级包发送至第二终端，减少固件升级包的下载流量，提高第二终端固件升级效率。
96.与此同时，服务器在接收到第一终端发送的第一固件升级请求后，可以确定当前存在第一固件版本的固件升级需求，此时生成第一差分升级包，可以避免服务器直接针对所有的历史固件版本生成匹配的差分升级包，进而有助于减少计算资源的浪费。
97.可选地，获取与第一固件版本对应的第一固件文件之前，方法还包括：
98.获取目标固件版本信息，目标固件版本信息包括位于第一固件版本与第二固件版本之间的固件版本的信息，第二固件版本为固件升级包对应的固件版本；
99.获取与第一固件版本对应的第一固件文件，包括：
100.在目标固件版本信息不存在强制更新固件版本的情况下，获取与第一固件版本对应的第一固件文件。
101.结合上文举例，第一固件版本可以是第一终端中固件的版本，版本号为上述的v1.1。而第二固件版本可以是固件升级包对应的版本，版本号为上述的v3。
102.容易理解的是，在v1.1固件版本与v3固件版本之间，可能还存在一个或多个固件版本。本实施例中，可以获取这一个或多个固件版本的信息，即上述的目标固件版本信息。
103.在一些示例中，目标固件版本信息可以具体包括固件版本及其类型，其中，固件版本的类型可以是指固件版本是否强制更新。
104.举例来说，基于获取的目标固件版本信息，服务器可以确定在v1.1固件版本与v3固件版本之间，存在v1.2固件版本与v2固件版本，且v1.2固件版本与v2固件版本均不为强制更新固件版本。此时，服务器可以进一步获取v1.1固件版本对应的第一固件文件，并依据第一固件文件与差分基准包生成第一差分升级包。
105.容易理解的是，当第一固件版本与第二固件版本之间不存在强制更新的固件版本时，基于差分包升级一般可以保证升级后固件版本的稳定性。
106.相应地，本实施例中，可以依据第一固件文件与差分基准包生成第一差分升级包。当服务器接收到第二终端发送的携带有第一固件版本的第二固件升级请求时，可以将该第一差分升级包发送至第二终端，以便第二终端通过差分升级的方式，将固件版本升级至第二固件版本。如此，可以在保证第二终端升级后的固件的稳定性的情况下，减少固件升级包的下载流量，提高固件升级效率。
107.可选地，获取目标固件版本信息之后，方法还包括：
108.在目标固件版本信息存在强制更新固件版本的情况下，获取第二固件文件，第二固件文件为距离第二固件版本最近的强制更新固件版本所对应的固件文件；
109.依据差分基准包与第二固件文件生成第二差分升级包；
110.在接收到第二终端发送的携带有第一固件版本的第二固件升级请求的情况下，向第二终端发送第二差分升级包与第二固件文件对应的第二全量升级包。
111.同样结合上文举例，第一固件版本的版本号为v1.1，第二固件版本的版本号为v3，在v1.1固件版本与v3固件版本之间还存在v1.2与v2两个固件版本。
112.若目标固件版本信息指示v1.2固件版本不为强制更新固件版本，但v2固件版本为强制更新固件版本，则v2固件版本可以认为是距离第二固件版本最近的强制更新固件版本，相应地，v2固件版本对应的固件文件为第二固件文件。
113.如上文实施例中，服务器中可以存储有各个固件版本对应的固件文件，而第二固件文件可以认为是历史上的一个固件版本对应的固件文件，相应地，该第二固件文件可以被服务器所获取。
114.服务器可以依据第二固件文件和差分基准包生成第二差分升级包，至于差分升级包的具体生成方式，此处不做赘述。
115.本实施例中，服务器在接收到第二终端发送的携带有第一固件版本的第二固件升级请求的情况下，可以将第二差分升级包与上述的第二固件文件对应的第二全量升级包发送至第二终端。
116.结合上文举例，从第二终端的角度来说，可以先基于第二全量升级包，从v1.1固件版本升级到v2这一强制更新固件版本，然后再基于第二差分升级包，从v2固件版本升级到v3固件版本。
117.当然，在实际应用中，第一固件版本与第二固件版本之间可以存在多个强制更新固件版本，比如，上述的v1.2与v2这两个固件版本均为强制更新固件版本。
118.在此情况下，服务器可以从这些强制更新固件版本中，确定距离v3固件版本最近的强制更新固件版本，即上述的v2固件版本。后续服务器可以进一步获取v2固件版本对应的第二固件文件，以及生成第二差分升级包等，此处不再重复说明。
119.针对强制更新固件版本，服务器通常可以将相关的全量升级包的提供给终端进行升级，由于各个全量升级包包括了用于固件升级的完整数据，本实施例中，服务器可以将距离第二固件版本最近的强制更新固件版本对应的第二固件文件发送至第二终端，以便使得第二终端的固件能够升级到比较稳定的版本；与此同时，基于第二固件文件与差分基准包生成的第二差分升级包，可以具有相对较小的数据量，进而有助于提高第二终端的固件升级效率。
120.可选地，编译配置文件，生成中间包，包括：
121.编译配置文件，得到包括编译后的预设条目的内核符号表；
122.将编译后的预设条目替换为条目镜像，得到基于条目镜像生成的内核符号表。
123.在一些示例中，编译配置文件的过程可以分为两个阶段。在第一阶段，服务器可以采用常规的方式对配置文件进行编译，在该阶段，上述的预设条目可以得到编译，有可能发生改变。而在第二阶段，可以将编译后的预设条目替换为条目镜像，该条目镜像可以是与原配置文件中的预设条目是相同的。
124.相应地，编译配置文件最终得到的内核符号表，可以是包括了上述条目镜像的内核符号表，从另一个角度来说，可以认为该内核符号表是基于条目镜像生成的。
125.一般，在制作配置文件时，其中的预设条目可以是预先和终端的固件中的预设条目进行匹配过的。本实施例中，通过将编译后的预设条目替换为条目镜像，有助于使得内核符号表中的预设条目，能够与终端的固件中的预设条目匹配，进而有助于实现终端固件的成功升级。
126.可选地，依据差分基准包与第一固件文件生成第一差分升级包，包括：
127.创建容器；
128.在容器中依据差分基准包与第一固件文件生成第一差分升级包。
129.如上文所示的，第一固件文件可以是第一终端中固件版本对应的固件文件。在实际应用中，需要进行固件升级的终端的数量可能存在多个，这些终端中的固件版本可能存在不同。相应地，服务器可能需要基于差分基准包与多个历史固件版本对应的固件文件分别生成差分升级包。
130.为了提高服务器生成差分升级包的效率，本实施例中，可以基于容器技术来生成第一差分升级包。
131.举例来说，服务器可以创建多个docker容器，一个docker容器可以分别基于差分基准包与一个历史固件版本的固件文件进行差分升级包的生成。多个docker容器中差分升级包的生成可以同步进行。
132.容易理解的是，本实施例中，第一固件文件可以认为是一个历史固件版本的固件文件，相应地，其也可以与差分基准包输入到其中的一个docker容器中，以便进行第一差分升级包的生成。
133.当然，本实施例中，容器的类型可以不限于docker容器，还可以是例如linux容器等类型的容器，此处不做一一举例。
134.本实施例中，基于容器技术来生成第一差分升级包，有助于提高服务器中差分升级包的整体生成效率。
135.可选地，编译配置文件，生成中间包，包括：
136.获取编译参数，编译参数包括预设中间包类型；
137.根据编译参数，编译配置文件，生成类型与预设中间包类型相匹配的中间包。
138.在一些举例中，编译配置文件前，可以对编译参数进行设置，比如，可以新增get-bin与get-ota两个编译参数。这两个编译参数可以分别对应bin中间包类型与ota中间包类型。
139.在根据编译参数编译配置文件后，可以生成bin类型的中间包与ota类型的中间包。
140.实际应用中，上述的编译参数可以根据需要进行设置。比如，可以仅新增get-bin，或者仅新增get-ota，或者是新增其他用于生成其他类型中间包的编译参数等。
141.本实施例中，基于包括预设中间包类型的编译参数来编译配置文件，有助于根据需要灵活获取相应类型的中间包，扩大固件升级文件处理方法的适用范围。
142.以下结合一个具体应用例来对本技术实施例提供的固件升级文件处理方法进行说明。在该具体应用例中，终端可以是大屏显示装置，服务器与终端可以进行通讯。
143.服务器可以包括固件录入模块、固件管理模块、版本升级查询模块、固件差分版本计算模块、固件差分模块以及出厂固件差分包生成模块。而大屏显示装置可以包括大屏升级模块。以下针对这些模块的功能进行具体说明。
144.固件录入模块可以在获取新版本的固件的情况下，录入固件信息以及固件的全量升级包，
145.比如，如图3所示，结合一个应用场景，服务器侧用户在获取到正式版固件后，可以登陆固件升级系统，手动录入固件信息以及上传全量升级包。其中，固件信息可以包括固件名称、版本号、内部型号、内部识别码、升级属性、是否强制更新、是全量还是可以差分升级、定向升级设备序列号、定向升级设备mac地址、升级说明等。
146.在固件信息设置为不可差分升级的情况下，直接发布全量升级包。而在固件信息设置为可差分升级的情况下，可以将固件信息放入差分队列等待差分，待后续完成差分后，发布得到的差分升级包。
147.固件管理模块可以用于新增固件，或者根据内部型号、内部识别码以及固件的名称查询固件。可编辑固件信息，可设置固件发布状态。
148.实际应用中，用户可以通过下拉选单过滤固件信息，或者在固件名称编辑框内输入固件名称的一部分文字来进一步过滤。
149.如图4所示，结合一些应用场景，内部型号可以是指终端的产品型号，或者是固件对应的型号。在用户选择内部型号的情况下，服务器可以展示该产品型号的固件列表。用户
可以进一步在固件列表中选择一个内部标识码。服务器响应于用户的选择输入，可以显示上述内部型号与内部标识码的固件列表。用户可以输入固件名称并点击查询。服务器可以进一步获取符合该名称的模糊查询后的固件列表。
150.大屏升级模块安装在大屏显示装置中，其可以定期向服务器发起新版本查询，如果有新的更新弹出提示询问用户是否更新，用户确认更新后引导系统执行升级操作。
151.如图5所示，结合一些应用场景，大屏升级模块每次启动完成后发起一次新版本查询，如果有新版本固件那么弹出询问框，提示用户是否升级，用户允许后根据返回的地址下载新版固件，下载完毕重启设备加载升级程序。
152.而在无新版本固件，或者用户手动取消升级的情况下，大屏升级模块本次查询完毕。
153.在一些可行的实施方式中，大屏升级模块也可以在用户点击大屏显示装置中的更新按钮的情况下，主动触发版本查询。
154.版本升级查询模块可以用于接收大屏升级模块发送过来的版本进行版本查询，反馈给大屏升级模块是否有可用升级固件。
155.如图5和图6所述，版本升级查询模块在接收到升级查询请求的情况下，调取数据库记录确认是否有可用升级固件，若有则返回固件下载地址，若无则返回没有可更新固件的查询结果。
156.固件差分版本计算模块用于当新的固件上传到服务器后将历史固件和当前固件可做差分的记录发送到差分队列，供后续差分模块调取。
157.在一个示例中，如图7所示，在服务器中存在新固件录入的情况下，固件差分版本计算模块首先根据内部类型和内部识别码确认同类固件，然后对比固件版本中的时间戳部分，如果有时间更新，则判断新固件是否为强制更新固件版本，若否，那么两个固件可以进行差分，将两个固件的版本信息写入差分队列等待差分；若是，则不予差分而跳过差分阶段。
158.固件差分模块用于读取差分队列，按照差分策略顺行处理各个版本和最新版本固件的差分包生成工作。
159.固件差分模块运行在守护进程内，每隔预设时长(例如1分钟)读取一次差分队列是否有新记录，如果有那么获取新纪录信息开始执行安卓差分程序生成差分包，并将差分包上传至云存储后返回下载地址，地址最终被存入数据库，供给固件升级查询模块查询使用。
160.出厂固件差分包生成模块可以用于生成中间包等，其可以包括shell脚本与python文件。其中，shell脚本可以具体用于对预设条目进行镜像与替换等；python文件可以用于修改默认的编译参数，例如上述的新增get-bin与get-ota。
161.如图8所示，图8是本技术中固件升级文件处理方法与常规技术中安卓系统差分升级过程的对比图。
162.服务器在接收到安卓系统源码的情况下，可以对安卓系统源码进行编译。安卓提供的标准ota程序处理(对应常规技术)，可以得到ota差分基准包，其中包括system.img，为便于区分，可以将基于标准ota程序处理得到的system.img称为文件a。
163.基于本技术的固件升级文件处理方法得到的ota差分基准包也包括system.img，
该system.img可以称为文件b。
164.用于写入到终端的bin文件也包括system.img，该system.img可以称为文件c。
165.标准ota程序编译过程中，预设条目可能发生改变，进而导致文件a与文件c之间存在不同。而本技术中，system.img中的预设条目即便在编译中改变，也可以通过条目镜像的替换而再次改回来，使得文件b与文件c之间完全相同。
166.相应地，同样是对中间包进行打包得到的差分升级包，标准ota程序得到的差分升级包由于升级校验时system分区有差异不通过，导致终端升级失败。而本技术得到的差分升级包则可以保证system分区一致，升级校验通过并使终端成功升级。
167.如图9所示，本技术实施例还提供了一种固件升级文件处理装置，装置包括：
168.第一获取模块901，用于获取配置文件；
169.读取生成模块902，用于读取配置文件中的预设条目，生成与预设条目对应的条目镜像；
170.编译模块903，用于编译配置文件，生成中间包，中间包包括基于条目镜像生成的内核符号表；
171.打包模块904，用于打包中间包，得到固件升级包。
172.可选地，固件升级包包括第一全量升级包；
173.相应地，固件升级文件处理装置，还可以包括：
174.接收模块，用于接收第一终端发送的第一固件升级请求；
175.第一发送模块，用于响应于第一固件升级请求，向第一终端发送第一全量升级包。
176.可选地，固件升级包还包括差分基准包，第一固件升级请求携带有第一固件版本；
177.相应地，固件升级文件处理装置，还可以包括：
178.第二获取模块，用于获取与第一固件版本对应的第一固件文件；
179.第一生成模块，用于依据差分基准包与第一固件文件生成第一差分升级包；
180.第二发送模块，用于在接收到第二终端发送的携带有第一固件版本的第二固件升级请求的情况下，向第二终端发送第一差分升级包。
181.可选地，固件升级文件处理装置，还可以包括：
182.第三获取模块，用于获取目标固件版本信息，目标固件版本信息包括位于第一固件版本与第二固件版本之间的固件版本的信息，第二固件版本为固件升级包对应的固件版本；
183.相应地，第二获取模块，可具体用于：
184.在目标固件版本信息不存在强制更新固件版本的情况下，获取与第一固件版本对应的第一固件文件。
185.可选地，固件升级文件处理装置，还可以包括：
186.第四获取模块，用于在目标固件版本信息存在强制更新固件版本的情况下，获取第二固件文件，第二固件文件为距离第二固件版本最近的强制更新固件版本所对应的固件文件；
187.第二生成模块，用于依据差分基准包与第二固件文件生成第二差分升级包；
188.第三发送模块，用于在接收到第二终端发送的携带有第一固件版本的第二固件升级请求的情况下，向第二终端发送第二差分升级包与第二固件文件对应的第二全量升级
包。
189.可选地，第一生成模块，包括：
190.创建单元，用于创建容器；
191.生成单元，用于在容器中依据差分基准包与第一固件文件生成第一差分升级包。
192.可选地，编译模块903，包括：
193.第一编译单元，用于编译配置文件，得到包括编译后的预设条目的内核符号表；
194.替换单元，用于将编译后的预设条目替换为条目镜像，得到基于条目镜像生成的内核符号表。
195.可选地，编译模块903，包括：
196.获取单元，用于获取编译参数，编译参数包括预设中间包类型；
197.第二编译单元，用于根据编译参数，编译配置文件，生成类型与预设中间包类型相匹配的中间包。
198.可选地，预设条目包括区块列表block_list与存储类型fs_type。
199.需要说明的是，该固件升级文件处理装置是与上述固件升级文件处理方法对应的装置，上述方法实施例中所有实现方式均适用于该装置的实施例中，也能达到相同的技术效果。
200.图10示出了本技术实施例提供的服务器的硬件结构示意图。
201.服务器可以包括处理器1001以及存储有计算机程序指令的存储器1002。
202.具体地，上述处理器1001可以包括中央处理器(cpu)，或者特定集成电路(application specific integrated circuit，asic)，或者可以被配置成实施本技术实施例的一个或多个集成电路。
203.存储器1002可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器1002可包括硬盘驱动器(hard disk drive，hdd)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(universal serial bus，usb)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器1002可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器1002可在综合网关容灾设备的内部或外部。在特定实施例中，存储器1002是非易失性固态存储器。
204.存储器可包括只读存储器(rom)，随机存取存储器(ram)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本公开的方法所描述的操作。
205.处理器1001通过读取并执行存储器1002中存储的计算机程序指令，以实现上述实施例中的任意一种固件升级文件处理方法。
206.在一个示例中，服务器还可包括通信接口1003和总线1010。其中，如图10所示，处理器1001、存储器1002、通信接口1003通过总线1010连接并完成相互间的通信。
207.通信接口1003，主要用于实现本技术实施例中各模块、装置、单元和/或设备之间的通信。
208.总线1010包括硬件、软件或两者。举例来说而非限制，总线可包括加速图形端口
(agp)或其他图形总线、增强工业标准架构(eisa)总线、前端总线(fsb)、超传输(ht)互连、工业标准架构(isa)总线、无限带宽互连、低引脚数(lpc)总线、存储器总线、微信道架构(mca)总线、外围组件互连(pci)总线、pci-express(pci-x)总线、串行高级技术附件(sata)总线、视频电子标准协会局部(vlb)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线1010可包括一个或多个总线。尽管本技术实施例描述和示出了特定的总线，但本技术考虑任何合适的总线或互连。
209.另外，结合上述实施例中的固件升级文件处理方法，本技术实施例可提供一种计算机存储介质来实现。该计算机存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种固件升级文件处理方法。
210.需要明确的是，本技术并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本技术的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本技术的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。
211.以上的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(asic)、适当的固件、插件、功能卡等等。当以软件方式实现时，本技术的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、rom、闪存、可擦除rom(erom)、软盘、cd-rom、光盘、硬盘、光纤介质、射频(rf)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。
212.还需要说明的是，本技术中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本技术不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。
213.上面参考根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。
214.以上，仅为本技术的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本技术的保护范围之内。