CN110032390B

CN110032390B - 一种实现多机型共升级包的方法、存储介质及智能终端

Info

Publication number: CN110032390B
Application number: CN201910250043.8A
Authority: CN
Inventors: 付华东; 许福; 王鹍; 戴宇明; 欧品志; 张炎
Original assignee: Shenzhen Skyworth RGB Electronics Co Ltd
Current assignee: Shenzhen Skyworth RGB Electronics Co Ltd
Priority date: 2019-03-29
Filing date: 2019-03-29
Publication date: 2022-09-27
Anticipated expiration: 2039-03-29
Also published as: CN110032390A

Abstract

本发明公开了一种实现多机型共升级包的方法、存储介质及智能终端，方法包括：集成编译device配置，将当前环境变量相同的所有机型文件均编译至同一个目录下；对派生机型的开机logo、Prop属性以及开机动画进行兼容性处理；当基础机型与派生机型的内嵌式存储器标准规格不相同时，增加相应派生机型的的内嵌式存储器标准规格，并通过编译的方式实现共升级包。本发明实现了基础机型与多个派生机型共用同一个升级包，降低了软件的维护成本，提高了开发和测试效率，同时大幅降低了对终端系统升级的维护成本，有利于实现对大规模数量智能终端的快速迭代升级。

Description

一种实现多机型共升级包的方法、存储介质及智能终端

技术领域

本发明涉及智能终端技术领域，尤其涉及的是一种实现多机型共升级包的方法、存储介质及智能终端。

背景技术

目前智能终端（如智能电视机）厂商通常都生产很多机型的终端，其实存在这种情况：很多基础机型都有派生机型，每个机芯对应的基础机型和多个派生机型终端硬件基本一致，或者在已量产的主板基础上增加/去掉HDMI/AV/DVB-C（有线数字)通道等差异性；软件只需要更改每个机型对应的系统配置文件，就可以在信号源界面，增加/去掉HDMI/AV/DVB-C通道的UI；基础机型和多个派生机型终端的开机logo，开机动画可能不太一样。

现有的技术为各个基础机型以及多个派生机型电视机对应单独的升级包，由于基础机型和多个派生机型电视机对应的硬件，软件差异性都比较小。针对基础机型和派生机型单独的升级包都要安排测试评审，导致测试效率低。此外，对已生产的电视机进行迭代系统升级时，每次迭代都要为各个基础机型和派生机型的终端准备对应的升级包，以分别对系统进行升级，升级维护成本过高，难以实现对大规模数量智能终端的快速迭代升级。

因此，现有技术还有待于改进和发展。

发明内容

本发明要解决的技术问题在于，针对现有技术的上述缺陷，提供一种实现多机型共升级包的方法、存储介质及智能终端，旨在解决现有技术中针对基础机型和派生机型都需要单独的升级包都要安排测试评审，导致测试效率低。此外，对已生产的电视机进行迭代系统升级时，每次迭代都要为各个基础机型和派生机型的终端准备对应的升级包，以分别对系统进行升级，升级维护成本过高，难以实现对大规模数量智能终端的快速迭代升级。

本发明解决技术问题所采用的技术方案如下：

一种实现多机型共升级包的方法，其中，所述方法包括：

集成编译device配置，将当前环境变量相同的所有机型文件均编译至同一个目录下；

对派生机型的开机logo、Prop属性以及开机动画进行兼容性处理；

当基础机型与派生机型的内嵌式存储器标准规格不相同时，增加相应派生机型的的内嵌式存储器标准规格，并通过编译的方式实现共升级包。

所述的实现多机型共升级包的方法，其中，对派生机型的开机logo进行兼容性处理包括：

当开机启动时，根据EEP存储器里的boot logo索引值加载第一张开机logo。

在surfaceFlinger.cpp中，在init函数中根据一系列逻辑将jpg图片路径给到底层接口，以实现对boot logo的更新；

在升级脚本中控制获取EEP存储器里的boot logo索引值，并根据所述索引值升级不同的开机logo文件，以实现OTA升级logo.img的兼容；

将jpg文件编译到/system/deriveLogo，将派生机型的 logo.img 打包到OTA升级包中。

所述的实现多机型共升级包的方法，其中，对派生机型的Prop属性进行兼容性处理包括：

在开机启动过程中根据 EEP存储器里配置的相关信息，读取EEP内的字段，设置环境变量，并加载对应的派生机型文件。

所述的实现多机型共升级包的方法，其中，所述字段包括：派生机芯,派生机型,品牌,派生机芯开关以及派生机型开关。

所述的实现多机型共升级包的方法，其中，对派生机型的开机动画进行兼容性处理包括：

根据ro.product.brand属性，加载对应的动画压缩包，如果没有则采用默认压缩包，并将多个开机动画同时集成到指定目录下，动画压缩包与默认压缩包通过配置平台勾选。

所述的实现多机型共升级包的方法，其中，所述当基础机型与派生机型的内嵌式存储器标准规格不相同时，增加相应派生机型的的内嵌式存储器标准规格，并通过编译的方式实现共升级包，包括：

在系统配置目录增加一个派生机型的内嵌式存储器标准规格的 bootargs文件，并编译生成两个bootargs.bin文件,其中一个是基础机型内嵌式存储器标准规格对应的bootargs.bin文件，另外一个是派生机型的内嵌式存储器标准规格对应的bootargs.bin文件；

在系统配置目录增加两个文件，包括：派生机型的内嵌式存储器标准规格对应的分区文件系统和派生机型的内嵌式存储器标准规格对应的分区表文件；

在系统配置文件里面增加 BOARD_USERDATAIMAGE_PARTITION_16G_SIZE；

修改编译目录下的输出文件；

修改派生机型的内嵌式存储器标准规格对应的bootargs文件，增加androidboot.emmc.size属性，此属性用来在升级脚本针对不同大小的 emmc 升级不同的bootargs；

修改编译目录下的打包文件，将不同大小内嵌式存储器标准规格的bootargs 打包到OTA包中；

修改升级脚本文件，加入根据androidboot.emmc.size 属性值来升级不同bootargs的功能；

修改lunch mk文件，加入宏定义。

所述的实现多机型共升级包的方法，其中，所述当基础机型与派生机型的内嵌式存储器标准规格不相同时，增加相应派生机型的的内嵌式存储器标准规格，并通过编译的方式实现共升级包，还包括：

将派生机型的内嵌式存储器标准规格对应的分区表文件编译成存储器标准规格的分区表文件，其中一个是基础机型内嵌式存储器标准规格对应的分区表文件，另外一个是派生机型的内嵌式存储器标准规格对应的分区表文件。

一种存储介质，其上存储有多条指令，其中，所述指令适于由处理器加载并执行，以执行实现上述任一项所述的实现多机型共升级包的方法的步骤。

一种智能终端，包括：处理器、与处理器通信连接的存储介质，其中，所述存储介质适于存储多条指令；所述处理器适于调用所述存储介质中的指令，以执行实现上述任一项所述的实现多机型共升级包的方法的步骤。

本发明的有益效果：本发明通集成编译device配置，并对派生机型的开机logo、Prop属性以及开机动画进行兼容性处理，实现了基础机型与多个派生机型共用同一个升级包，降低了软件的维护成本，提高了开发和测试效率，同时大幅降低了对终端系统升级的维护成本，有利于实现对大规模数量智能终端的快速迭代升级。

为电视机的研发设计，测试，生产，品质等节省和优化了非常可观的人力资源和时间成本，具有非常高的现实利益价值。

附图说明

图1是本发明提供的实现多机型共升级包的方法的较佳实施例的流程图。

图2是本发明提供的基于安卓系统开机优化方法中对派生机型的开机logo进行兼容性处理的较佳流程图。

图3是本发明提供的基于安卓系统开机优化方法中对派生机型的prop属性进行兼容性处理的较佳流程图。

图4是本发明提供的智能终端的功能原理图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明提供的一种实现多机型共升级包的方法，可以应用于智能终端中。其中，智能终端可以但不限于是各种电视、个人计算机、笔记本电脑、手机、平板电脑、车载电脑和便携式可穿戴设备。本发明的终端采用多核处理器。其中，智能终端的处理器可以为中央处理器（Central Processing Unit，CPU），图形处理器（Graphics Processing Unit，GPU）、视频处理单元（Video Processing Unit，VPU）等中的至少一种。

由于现有技术中基础机型和派生机型单独的升级包都要安排测试评审，导致测试效率低，此外，对已生产的电视机进行迭代系统升级时，每次迭代都为各个基础机型和派生机型的终端准备对应的升级包，以分别对系统进行升级，升级维护成本过高，难以实现对大规模数量智能终端的快速迭代升级。为了解决上述问题，本实施例提供一种实现多机型共升级包的方法，具体如图1中所示，包括以下步骤：

步骤S100、集成编译device配置，将当前环境变量相同的所有机型文件均编译至同一个目录下；

步骤S200、对派生机型的开机标志、Prop属性以及开机动画进行兼容性处理；

步骤S300、当基础机型与派生机型的内嵌式存储器标准规格不相同时，增加相应派生机型的的内嵌式存储器标准规格，并通过编译的方式实现共升级包。

具体地，本实施例以海思的Hi3751V551方案实现共升级包为例进行，8H56-Q3A为基础机型，8H57-H5和8H57-C60为派生机型。

其中，EEP（Electrically Erasable Programmable）存储器或者EMMC（EmbeddedMultiMediaCard为MMC协会所订立的内嵌式存储器标准规格），占用 2+16+16=34个字节，分别用于存放：

品牌开机 logo（2字节）：品牌索引，用于bootloader区分第一张logo；

派生机芯开关（1字节）+派生机芯完整字符（15字节）

派生机型开关（1字节）+派生机型完整字符（15字节）

由于共OTA升级包的前提：lunch选择的TARGET_PRODUCT（环境变量）必须一致。禁止出现TARGET_PRODUCT相同，但是编译出来的OTA包不一样，比如开新分支lunch还不变。因此本实施例采用集成编译device（策略）配置，在编译时，将当前的TARGET_PRODUCT相同的所有机型文件（机芯_机型.prop）都编译到同一目录（/system/vendor/deriveproperty/）下。

进一步地，本实施例中对派生机型的开机logo、Prop属性以及开机动画进行兼容性处理。具体地，当开机启动时，根据EEP（Electrically Erasable Programmable）存储器里的boot logo索引值加载第一张开机logo。开机 logo （开机标志）的兼容主要包括三个部分：1、代码的实现；2、OTA (Over-the-Air Technology)升级 logo.img 的兼容；3、编译策略配置。针对代码的实现，代码的实现是在surfaceFlinger.cpp(SurfaceFlinger是Android multimedia的一个部分，在Android 的实现中它是一个service，提供系统范围内的surface composer功能，它能够将各种应用程序的2D、3D surface进行组合) 中，在init 函数中根据一系列逻辑调用底层接口设置，具体如图2中所示。本实施例以海思平台为例，包括以下步骤：

步骤201、在SurfaceFlinger的Init函数中加入创建开机标志。

步骤202、判断派生标志成功标识是否存在；若是则执行步骤204；否则执行步骤203。

步骤203、执行返回。

步骤204、判断派生机机芯、机型开关是否为打开状态；若是则执行步骤206；若否则执行步骤205。

步骤205、执行返回。

步骤206、判断派生机 EEP中开机标志索引是否已经设置；若是则执行步骤208；若否则执行步骤207。

步骤207、执行返回。

步骤208、判断要设置的派生机jpg图片是否存在且可读；若是则执行步骤210；若否则执行步骤209。

步骤209、执行返回。

步骤210、更新开机更新标志。

步骤211、判断更新开机标志是否成功；若是则执行步骤213；若否则执行步骤212。

步骤212、执行返回。

步骤213、设置成功标志为创建标志文件。

本实施例中的海思平台是通过将jpg图片路径给到底层接口来实现boot logo（开机标志）更新。给出的jpg图片要求base line格式，所以针对普通的图片，需要通过海思的hitool（海思芯片烧写工具）转换。对于OTA升级logo.img的兼容：由于 OTA升级包涉及到logo.img 的升级，因此要考虑OTA升级兼容不同logo.img 的情况，实现对应型号升级对应的logo.img。升级策略是在升级脚本中控制： package_extract_file(getprop(“ro.boot.deriveLogo”) + “_”“logo.img”,“/dev/block/platform/hi_mci.1/by-name/logo”);

其中ro.boot.deriveLogo是获取的EEP里面的boot logo索引值，根据这个值来升级不同的开机logo文件（logo.img）。

编译策略配置：由于更新boot logo需要jpg文件， OTA升级需要 logo.img，因此在系统里面需要将两种类型的文件编译到系统指定目录中。jpg文件是编译到/system/deriveLogo，派生机的 logo.img 打包到OTA升级包中。本实施例中的海思平台是在编译目录/device/skyworth/common中增加deriveLogo和deriveLogoImg 两个目录，用于存在jpg和logo.img。deriveLogo 规则如下：在此目录增加派生机 boot logo jpg 图片，按照EEP 0x2A3 和 0x2A4 这两个地址存放的值命名，例如：如果 0x2A3 地址存放的值为0x00， 0x2A4 地址存放的值为 0x01，那么此派生机 boot logo jpg的名字为：0001.jpg。deriveLogoImg 规则如下：在此目录增加派生机的logo.img，按照 EEP 0x2A3 和 0x2A4这两个地址存放的的值命名，例如：如果 0x2A3 地址存放的值为0x00，0x2A4地址存放的值为 0x01，那么此派生机logo.img 的名字为：0001_logo.img编译 jpg 图片到system/deriveLogo 目录。编译派生机 logo.img 到 out/xxx/Emmc目录以及把logo.img文件打包到OTA升级包。

进一步地，Recovery使用统一的init进程，在init进程处理完derive info（派生信息）字段后，直接使用属性：ro.build.skymodel，ro.build.skytype即可用来做机芯、机型判断，用于Recovery菜单UI界面过滤升级包。OTA包升级脚本去除对机芯、机型的校验，只用android标准的ro.product.name（就是TARGET_PRODUCT的值）来做校验，该属性在Recovery默认的default.prop中即可获取，直接使用即可。

针对prop（文档向导说明文件）属性的兼容性处理，主要是依据在开机启动过程中根据EEP（EEPROM 或 EMMC（param分区）统称EEP）里面配置的相关信息，读取EEP内5个字段，设置环境变量：android boot.derive info=派生机芯，派生机型，品牌，派生机芯开关，派生机型开关（5个字段），加载对应的派生机芯_机型.prop 文件。具体如图3中所示，包括如下步骤：

步骤301、设置EEP ：派生机型、派生机芯、派生机型开关、派生机芯开关。

步骤302、Boot获取对应的EEP数据。

步骤303、Boot获取Bootargs参数。 bootargs是环境变量中的重中之重，甚至可以说整个环境变量都是围绕着bootargs来设置的。

步骤304、将获取到的EEP各项数据通过androidboot权限方式配置到bootargs中。

步骤305、通过改变或增加环境变量的方式重新设置bootargs参数。

步骤306、Init进程获取boot通过androidboot权限映射过来的属性。

步骤307、根据获取的属性加载对应的prop文件。prop文件是文档向导说明文件。

步骤308、上层按照获取到的属性进行相应的处理。

针对开机动画进行兼容性处理，ro.product.brand在机芯_机型.prop文件里面有定义：例如8H57_H5.prop文件里面定义：ro.product.brand=Skyworth，8H57_C60.prop文件里面定义：ro.product.brand=Coocaa。根据ro.product.brand属性，加载对应的动画压缩包（bootanimation_${ro.product.brand}.zip），如果没有则采用默认压缩包（bootanimation.zip。Skyworth、Coocaa）等多个开机动画同时集成到/system/media/下bootanimation_Skyworth.zip，bootanimation_Coocaa.zip，通过配置平台勾选。

优选地，driverbase工厂等获取产品相关配置，屏参等，根据ro.build.skymodel，ro.build.skytype，读取对应/xxx/机芯_机型相关数据。上层应用启动时，根据ro.build.skymodel，ro.build.skytype，读取 /system/pcfg/机芯_机型目录下对应的配置文件，基础机型和派生机型的相关差异项可以体现在系统配置文件。例如8H57_H5带DVB-C（有线数字）通道，对应的general_config.xml文件配置如下： <config name="CONFIG_SOURCE_LIST"value="ATV|AV|DTMB|DVBC|HDMI@0|HDMI@1" /> 。8H57_C60不带DVB-C（有线数字）通道，对应的general_config.xml文件配置如下：<config name="CONFIG_SOURCE_LIST"value="ATV|AV|DTMB|HDMI@0|HDMI@1" />，软件只需要更改每个机型对应的系统配置文件，就可以在信号源界面正确显示支持的所有通道UI。

进一步地，当基础机型与派生机型的EMMC（内嵌式存储器标准规格）大小一样，可以实现共OTA升级包和共生产烧录包；但是有些派生机型的EMMC大小也可能不一样，那么就需要增加派生机型不同 EMMC 大小（其中某个派生机型为8G EMMC，另外的派生机型为16GEMMC）的共升级包方案：由于EMMC大小不一样，不能共生产烧录包，可以通过编译方式实现共升级包，生成两份EMMC 镜像和一个公共的OTA升级包。而当不同的EMMC大小共升级包主要涉及到： 1、 bootargs 的更改； 2、 data 分区文件系统大小更改；3、分区表文件中data分区大小的更改。由于某些派生机型的EMMC大小不一样，要实现共升级包，分区表文件里面除了最后一个data分区根据实际的EMMC大小进行分配导致data分区大小不一样外，其它的所有分区大小都必须一样，否则无法实现共升级包。本实施例作出如下改动如下：

1）在系统配置目录增加一派生机型的内嵌式存储器标准规格的 bootargs文件，并编译生成两个bootargs.bin文件,其中一个是基础机型内嵌式存储器标准规格对应的bootargs.bin文件，另外一个是派生机型的内嵌式存储器标准规格对应的bootargs.bin文件。具体地，本实施例中增加的是派生16G emmc bootargs文件，此文件用来针对 16G EMMC 的 bootargs，最终编译生成两个bootargs.bin文件,其中一个是8G EMMC 对应的bootargs.bin，另外一个是16G EMMC对应的bootargs.bin。 2）在系统配置目录增加两个文件，包括：派生机型的内嵌式存储器标准规格对应的分区文件系统和派生机型的内嵌式存储器标准规格对应的分区表文件。优选地，将派生机型的内嵌式存储器标准规格对应的分区表文件编译成存储器标准规格的分区表文件，其中一个是基础机型内嵌式存储器标准规格对应的分区表文件，另外一个是派生机型的内嵌式存储器标准规格对应的分区表文件。本实施中增加的16G Emmc分区文件系统和16G Emmc分区表文件，针对 16G 的 EMMC，最终编译生成两个Emmc分区表文件，其中一个是8G EMMC ，另外一个是16G EMMC对应的分区表文件。 3）在系统配置文件里面增加 BOARD_USERDATAIMAGE_PARTITION_16G_SIZE，这个变量的大小表示 16G EMMC data 分区的大小，这个变量将会在 ext4.mk 里面编译生成 userdata_16G.img。 4）修改编译目录下的输出文件，编译生成userdata_16G.img 和 userdata.img 以及 Emmc目录和 Emmc_16G 目录。上面 1、 2 所述的 bootargs.bin 和 emmc.xml 按照不同 emmc的大小分别编译到 Emmc 和 Emmc_16G 目录。 5）修改16G bootargs文件，在此文件中增加androidboot.emmc.size=16G 属性，此属性用来在升级脚本针对不同大小的 emmc 升级不同的bootargs文件。 6）修改编译目录下的打包文件，将不同大小Emmc的bootargs 打包到OTA包中。

7）修改升级脚本文件，加入根据androidboot.emmc.size 属性值来升级不同bootargs的功能。 8）修改lunch mk文件，加入宏定义 EMMC_SIZE_DERIVE_16G := YES，增加 USERDATA_IMAGE_16G_SIZE := 11900，定义 16G EMMC data 分区的大小。通过 sed方式修改 16G emmc bootargs文件， 16G Emmc分区文件系统以及16G Emmc分区表文件中data分区的大小。

基于上述实施例，本发明还提供了一种智能终端，其原理框图可以如图4所示。该智能终端包括通过系统总线连接的处理器、存储器、网络接口、显示屏、温度传感器。其中，该智能终端的处理器用于提供计算和控制能力。该智能终端的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该智能终端的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种实现多机型共升级包的方法。该智能终端的显示屏可以是液晶显示屏或者电子墨水显示屏，该智能终端的温度传感器是预先在智能终端内部设置，用于检测内部设备的当前运行温度。

本领域技术人员可以理解，图4中示出的原理框图，仅仅是与本发明方案相关的部分结构的框图，并不构成对本发明方案所应用于其上的智能终端的限定，具体的智能终端可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种智能终端，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时至少可以实现以下步骤：

集成编译device配置，将当前TARGET_PRODUCT相同的所有机型文件均编译至同一个目录下；

在其中一个实施例中，该处理器执行计算机程序时还可以实现以下步骤：当开机启动时，根据EEP存储器里的boot logo索引值加载第一张开机logo。

在其中一个实施例中，该处理器执行计算机程序时还可以实现以下步骤：在init函数中根据一系列逻辑将jpg图片路径给到底层接口，以实现对boot logo的更新；

在其中一个实施例中，该处理器执行计算机程序时还可以实现以下步骤：在开机启动过程中根据 EEP存储器里配置的相关信息，读取EEP内的字段，设置环境变量，并加载对应的派生机型文件。所述字段包括：派生机芯,派生机型,品牌,派生机芯开关以及派生机型开关。

在其中一个实施例中，该处理器执行计算机程序时还可以实现以下步骤：根据ro.product.brand属性，加载对应的动画压缩包，如果没有则采用默认压缩包，并将多个开机动画同时集成到指定目录下，动画压缩包与默认压缩包通过配置平台勾选。

在其中一个实施例中，该处理器执行计算机程序时还可以实现以下步骤：

在系统配置文件里面增加 BOARD_USERDATAIMAGE_PARTITION_16G_SIZE；

修改编译目录下的输出文件；

修改lunch mk文件，加入宏定义。

在其中一个实施例中，该处理器执行计算机程序时还可以实现以下步骤：将派生机型的内嵌式存储器标准规格对应的分区表文件编译成存储器标准规格的分区表文件，其中一个是基础机型内嵌式存储器标准规格对应的分区表文件，另外一个是派生机型的内嵌式存储器标准规格对应的分区表文件。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本发明所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

综上所述，本发明公开了一种实现多机型共升级包的方法、存储介质及智能终端，方法包括：方法包括：集成编译device配置，将当前TARGET_PRODUCT相同的所有机型文件均编译至同一个目录下；对派生机型的开机logo、Prop属性以及开机动画进行兼容性处理；当基础机型与派生机型的内嵌式存储器标准规格不相同时，增加相应派生机型的的内嵌式存储器标准规格，并通过编译的方式实现共升级包。本发明实现了基础机型与多个派生机型共用同一个升级包，降低了软件的维护成本，提高了开发和测试效率，同时大幅降低了对终端系统升级的维护成本，有利于实现对大规模数量智能终端的快速迭代升级。为电视机的研发设计，测试，生产，品质等节省和优化了非常可观的人力资源和时间成本，具有非常高的现实利益价值。

应当理解的是，本发明的应用不限于上述的举例，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，所有这些改进和变换都应属于本发明所附权利要求的保护范围。

Claims

1.一种实现多机型共用升级包的方法，其特征在于，所述方法包括：

当基础机型与派生机型的内嵌式存储器标准规格不相同时，增加相应派生机型的内嵌式存储器标准规格，并通过编译的方式实现共用升级包；

对派生机型的Prop属性进行兼容性处理包括：

在开机启动过程中根据 EEP存储器里配置的相关信息，读取EEP内的字段，设置环境变量，并加载对应的派生机型文件；

对派生机型的开机logo进行兼容性处理包括：

当开机启动时，根据EEP存储器里的boot logo索引值加载第一张开机logo；

对派生机型的开机logo进行兼容性处理包括：

将jpg文件编译到/system/deriveLogo，将派生机型的 logo.img 打包到OTA升级包中；

对派生机型的开机动画进行兼容性处理包括：

2.根据权利要求1所述的实现多机型共用升级包的方法，其特征在于，所述字段包括：派生机芯,派生机型，品牌，派生机芯开关以及派生机型开关。

3.根据权利要求1所述的实现多机型共用升级包的方法，其特征在于，所述当基础机型与派生机型的内嵌式存储器标准规格不相同时，增加相应派生机型的内嵌式存储器标准规格，并通过编译的方式实现共用升级包，包括：

在系统配置文件里面增加 BOARD_USERDATAIMAGE_PARTITION_16G_SIZE；

修改编译目录下的输出文件；

修改编译目录下的打包文件，将不同大小内嵌式存储器标准规格的bootargs 打包到OTA升级包中；

修改升级脚本文件，加入根据androidboot.emmc.size 属性值来升级不同 bootargs的功能；

修改lunch mk文件，加入宏定义。

4.根据权利要求3所述的实现多机型共用升级包的方法，其特征在于，所述当基础机型与派生机型的内嵌式存储器标准规格不相同时，增加相应派生机型的内嵌式存储器标准规格，并通过编译的方式实现共用升级包，还包括：

5.一种存储介质，其上存储有多条指令，其特征在于，所述指令适于由处理器加载并执行，以执行实现上述权利要求1-4任一项所述的实现多机型共用升级包的方法的步骤。

6.一种智能终端，包括：处理器、与处理器通信连接的存储介质，其特征在于，所述存储介质适于存储多条指令；所述处理器适于调用所述存储介质中的指令，以执行实现上述权利要求1-4任一项所述的实现多机型共用升级包的方法的步骤。