一种车机中预装应用的升级方法、装置、设备和存储介质

技术领域

本发明涉及智能网联汽车技术领域，尤其涉及一种车机中预装应用的升级方法、装置、设备和存储介质。

背景技术

随着汽车智能化及网络化程度越来越高，软件定义汽车已成为流行趋势，汽车软件集成度及复杂度也随之提高。通过对车机应用软件的升级，可实现对软件问题的修复，并满足用户不断更新迭代的个性化需求。

现有的应用升级方法可根据车机的系统版本控制应用的升级，而实际中，不同应用之间可能存在依赖关系。例如，应用A在运行的过程中需依赖应用B的某些功能，因此，要使得升级后的应用A能够正常运行，则需保证升级后的应用A能够与车机当前的应用B适配，而现有的应用升级方法无法做到这一点。

发明内容

本发明的目的在于提供一种车机中预装应用的升级方法、装置、设备和存储介质，以解决现有技术中无法保证升级后的应用与其依赖的应用相适配的问题。

为了实现上述目的，本发明采用的技术方案如下：

第一方面，本发明实施例提供了一种车机中预装应用的升级方法，应用于服务器，该升级方法包括：接收来自车机的升级请求信息，升级请求信息包括：待升级的第一预装应用的当前版本信息；基于升级请求信息，以及车机的第二预装应用的当前版本信息，确定待升级的第一预装应用的目标版本；其中，目标版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配；第一预装应用与第二预装应用存在依赖关系；向车机发送目标版本的升级包，升级包用于将待升级的第一预装应用从当前版本升级到目标版本。

根据上述技术手段，由于服务器在确定待升级的第一预装应用的目标版本的过程中，将与该第一预装应用存在依赖关系的第二预装应用的当前版本信息作为考虑因素之一，并使得目标版本与第二预装应用的当前版本适配，因此可避免升级后的第一预装应用与其依赖的第二预装应用的当前版本无法适配的问题。

进一步，基于升级请求信息，以及车机的第二预装应用的当前版本信息，确定待升级的第一预装应用的目标版本，包括：获取第一预装应用的候选版本集合；将候选版本集合中满足第一条件的候选版本确定为目标版本；其中，第一条件包括：候选版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配。

根据上述技术手段，服务器可从第一预装应用的各个候选版本中，确定出一个版本号大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配的目标版本，从而保证了将第一预装应用升级到目标版本后，该目标版本能够与车机上当前已安装的第二预装应用相适配。

进一步，升级请求信息还包括：车机的车辆识别码，和/或，车机的系统版本信息；第一条件还包括：候选版本能够与车机的车辆识别码和/或车机的系统版本适配。

根据上述技术手段，服务器在确定第一预装应用的目标版本的过程中，还可以考虑目标版本与车机的车辆识别码和/或系统版本信息之间的适配问题，这样，增加了确定目标版本时所依据的参数维度，从而可使得所确定的目标版本的精细化程度更高。

进一步，升级请求信息还包括：待升级的第一预装应用的当前版本所携带的第一参数；其中，待升级的第一预装应用能够从当前版本成功升级到新版本的条件包括：新版本的第一预装应用携带该第一参数；第一条件还包括：候选版本携带该第一参数。

根据上述技术手段，由于要将第一预装应用从当前版本成功升级到新版本，需满足新版本的第一预装应用也携带该第一参数，因此，在第一预装应用的当前版本携带第一参数的情况下，通过令最终确定出的目标版本也携带第一参数，可避免由于目标版本未携带第一参数而导致的升级失败。

进一步，在确定待升级的第一预装应用的目标版本之前，该升级方法还包括：确定各个候选版本可适配的第二预装应用的版本的范围和/或可适配的车机系统版本的范围。

根据上述技术手段，服务器在确定目标版本之前，可先确定各个候选版本可适配的第二预装应用的版本的范围和/或各个候选版本可适配的车机系统版本的范围，从而可为后续确定目标版本提供参考信息。

进一步，在确定待升级的第一预装应用的目标版本之前，该升级方法还包括：确定与第一预装应用存在依赖关系的第二预装应用，并获取车机的第二预装应用的当前版本信息。

根据上述技术手段，服务器可在确定目标版本之前，确定与第一预装应用存在依赖关系的第二预装应用，并可获取车机的第二预装应用的当前版本信息，从而，服务器在确定目标版本的过程中，可将与第一预装应用存在依赖关系的第二预装应用的当前版本信息作为考虑因素之一，以避免升级后的第一预装应用与车机当前的第二预装应用的版本无法适配的问题。

第二方面，本发明实施例提供了一种车机中预装应用的升级方法，应用于车机，该升级方法包括：向服务器发送升级请求信息，升级请求信息包括：待升级的第一预装应用的当前版本信息；接收来自服务器的第一预装应用的目标版本的升级包，升级包用于将待升级的第一预装应用从当前版本升级到目标版本；其中，目标版本是由服务器基于升级请求信息，以及车机的第二预装应用的当前版本信息确定的；其中，目标版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配；第一预装应用与第二预装应用存在依赖关系。

根据上述技术手段，由于服务器在确定待升级的第一预装应用的目标版本的过程中，将与该第一预装应用存在依赖关系的第二预装应用的当前版本信息作为考虑因素之一，并使得目标版本与第二预装应用的当前版本适配，因此可避免升级后的第一预装应用与其依赖的第二预装应用的当前版本无法适配的问题。

进一步，该升级方法还包括：判断目标版本是否大于待升级的第一预装应用的当前版本；若目标版本大于待升级的第一预装应用的当前版本，则将目标版本显示在车机的应用升级列表中，并显示用于升级第一预装应用的升级选项；若升级选项被选中，则基于升级包，将待升级的第一预装应用从当前版本升级到目标版本。

根据上述技术手段，车机在对待升级的第一预装应用进行升级之前，可对是否符合升级规则进行检查，若目标版本大于待升级的第一预装应用的当前版本，则说明符合升级规则，进而可将目标版本显示在车机的应用升级列表中，如此，可确保升级的正常进行。

进一步，该升级方法还包括：在目标版本大于待升级的第一预装应用的当前版本的情况下，判断目标版本是否携带强制更新标签；若目标版本未携带强制更新标签，则显示用于忽略升级第一预装应用的忽略选项；若忽略选项被选中，则将目标版本从车机的应用升级列表中删除。

根据上述技术手段，若目标版本未携带强制更新标签，则可向用户提供忽略升级选项。这样，用户可根据个人需求忽略掉不希望升级的预装应用，从而有利于满足用户的个性化需求。

进一步，该升级方法还包括：将车机中可通过非空中下载方式进行升级的待升级预装应用确定为待升级的第一预装应用。

根据上述技术手段，车机可将可通过非OTA方式进行升级的预装应用作为待升级的第一预装应用，进而可通过向服务器发送升级请求信息的方式获取该第一预装应用的升级包。也即，待升级的第一预装应用可通过非OTA的方式进行独立升级，如此，能够快速完成对该第一预装应用的升级，并能够减少车机的OTA频次。

第三方面，本发明实施例提供了一种车机中预装应用的升级装置，该升级装置包括：第一接收单元，用于接收来自车机的升级请求信息，升级请求信息包括：待升级的第一预装应用的当前版本信息；第一确定单元，用于基于升级请求信息，以及车机的第二预装应用的当前版本信息，确定待升级的第一预装应用的目标版本；其中，目标版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配；第一预装应用与第二预装应用存在依赖关系；第一发送单元，用于向车机发送目标版本的升级包，升级包用于将待升级的第一预装应用从当前版本升级到目标版本。

第四方面，本发明实施例提供了一种车机中预装应用的升级装置，该升级装置包括：第二发送单元，用于向服务器发送升级请求信息，升级请求信息包括：待升级的第一预装应用的当前版本信息；第二接收单元，用于接收来自服务器的第一预装应用的目标版本的升级包，升级包用于将待升级的第一预装应用从当前版本升级到目标版本；其中，目标版本是由服务器基于升级请求信息，以及车机的第二预装应用的当前版本信息确定的；其中，目标版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配；第一预装应用与第二预装应用存在依赖关系。

第五方面，本发明实施例提供了一种车机中预装应用的升级设备，该升级设备包括存储器和处理器；其中，存储器，用于存储计算机可执行指令；处理器，与该存储器连接，用于通过执行该计算机可执行指令，实现如第一方面或第二方面所述的方法。

第六方面，本发明实施例提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，计算机程序被至少一个处理器执行时实现如第一方面或第二方面所述的方法。

本发明的有益效果：由于服务器在确定待升级的第一预装应用的目标版本的过程中，将与该第一预装应用存在依赖关系的第二预装应用的当前版本信息作为考虑因素之一，并使得目标版本与第二预装应用的当前版本适配，因此可避免升级后的第一预装应用与其依赖的第二预装应用的版本无法适配的问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本公开的技术方案。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本发明的实施例，并与说明书一起用于说明本发明的技术方案。

图1为本发明实施例提供的一种车机中预装应用的升级方法的流程示意图；

图2为本发明实施例提供的一种判断预装应用是否可通过非OTA方式进行升级的流程示意图；

图3为本发明实施例提供的车机中预装应用的升级方法的一种可能的实现流程示意图；

图4为本发明实施例提供的一种车机中预装应用的升级装置的组成结构示意图；

图5为本发明实施例提供的另一种车机中预装应用的升级装置的组成结构示意图；

图6为本发明实施例中车机中预装应用的升级设备的一种硬件实体示意图。

具体实施方式

为了能够更加详尽地了解本发明实施例的特点与技术内容，下面结合附图对本发明实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本发明实施例。

除非另有定义，本发明实施例所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本发明实施例中所使用的术语只是为了描述本发明实施例的目的，不是旨在限制本发明。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。还需要指出，本发明实施例所涉及的术语“第一第二第三”仅是用于区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一第二第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本发明实施例能够以除了在这里图示或描述的以外的顺序实施。

应理解，本发明实施例中的术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

随着汽车智能化及网络化程度越来越高，软件定义汽车已成为流行趋势，汽车软件集成度及复杂度也随之提高。通过对车机应用软件的升级，可实现对软件问题的修复，并满足用户不断更新迭代的个性化需求。

现有的应用升级方法可根据车机的系统版本控制应用的升级。例如，公布号为CN114721691A的中国专利公开了一种更新车机端预装应用的方法，该方法可根据当前系统版本获取应用包。在该方法中，车载应用商店可以获取当前车辆系统的版本号，获取系统版本号之后将版本号上传到云端与云端配置的最低版本号进行比较，若当前系统版本号满足云端配置的最低版本号需求，车机应用商店则可以下载对应的预装应用包；如当前车辆车机系统版本号不满足系统最低版本要求，则无法获取预装应用。

该方法的局限性在于：虽然可以通过系统版本来控制应用的升级，但使用的参数单一，无法做到精细化的升级控制。例如，该方案在应用升级过程中只考虑了应用与系统版本的依赖关系。而实际中，应用与应用(或服务)之间也可能存在依赖关系。升级过程中，如果应用依赖其他特定版本的应用，那么实际上需要被依赖的应用或服务已存在且已升级到该特定版本。现有方案由于没有考虑当前系统已安装应用的相关版本信息，故可能导致升级之后的应用与其所依赖的其他应用的版本不适配，从而造成无法使用的情况，进而给用户带来不便。

在另一些现有的应用升级方案中，若已安装应用的版本号小于远程应用版本号，即可将应用升级为远程应用版本，该方案同样无法避免升级之后的应用与其所依赖的其他应用不适配的问题。

鉴于此，本发明实施例提供一种车机中预装应用的升级方法、装置、设备和存储介质。

在本发明实施例的方法中，服务器(服务端)可基于待升级的第一预装应用的当前版本信息，以及与该第一预装应用存在依赖关系的第二预装应用的当前版本信息，确定待升级的第一预装应用的目标版本，并向车机(车机端)发送该目标版本的升级包。其中，服务器确定的目标版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配。由于服务器在确定待升级的第一预装应用的目标版本的过程中，将与该第一预装应用存在依赖关系的第二预装应用的当前版本信息作为考虑因素之一，并使得目标版本与第二预装应用的当前版本适配，因此可避免升级后的第一预装应用与其依赖的第二预装应用的当前版本无法适配的问题。

下面结合附图对本发明各实施例进行详细说明。

图1示出了本发明实施例提供的一种车机中预装应用的升级方法。该方法可包括：

S101，车机向服务器发送升级请求信息。

相应地，服务器可接收来自车机的升级请求信息。该升级请求信息可用于请求服务器对待升级的第一预装应用进行版本检查，以检查是否存在该第一预装应用的可升级版本。其中，升级请求信息可包括：待升级的第一预装应用的当前版本信息。

在一些实施例中，升级请求信息还可以包括以下1)至3)中的至少一项信息：

1)车机的车辆识别码(Vehicle Identification Number，VIN)。

本发明实施例中，VIN还可以称为车架号，可用于识别车机身份。

2)车机的系统版本信息。

本发明实施例中，系统版本还可以称为操作系统(Operating System，OS)版本或ROM版本。

3)待升级的第一预装应用的当前版本所携带的第一参数。

其中，待升级的第一预装应用能够从当前版本成功升级到新版本的条件包括：新版本的第一预装应用携带该第一参数。

也就是说，在第一预装应用的当前版本携带第一参数的情况下，若要将第一预装应用从当前版本成功升级到新版本，则要求新版本的第一预装应用也携带该第一参数。若新版本的第一预装应用中不存在该第一参数，则会导致升级失败。作为示例，该第一参数例如可以为第一预装应用相关的Manifest配置中的“android:sharedUserId”。在该情况下，对第一预装应用进行升级时，要求新版本的第一预装应用相关的Manifest配置中也存在“android:sharedUserId”这一参数，若不存在，则会导致升级失败。

在一些实施例中，车机在向服务器发送升级请求信息之前，该方法还可以包括：在车机端，将车机中可通过非空中下载(Over-The-Air，OTA)方式进行升级的待升级预装应用确定为待升级的第一预装应用。

作为一种实现方式，车机可根据待升级预装应用是否为永久性(即persistent属性)的预装应用来判断该待升级预装应用是否可通过非OTA方式进行升级。例如，若预装应用为非persistent属性，则表明该预装应用可采用非OTA方式进行升级，或者说，该预装应用可采用独立升级的方式进行升级；若预装应用为persistent属性，则表明该预装应用不可采用非OTA方式进行升级，或者说，该预装应用需采用OTA方式进行升级。应理解，无论预装应用是带有桌面启动器(Launcher)的预装应用，还是未带有桌面启动器的预装应用，均可适用于该判断方式。

图2为本发明实施例提供的一种判断预装应用是否可通过非OTA方式进行升级的流程示意图。如图2所示，若预装应用为persistent属性的应用，则该预装应用需采用OTA方式进行升级；若该预装应用为非persistent属性的应用，则该预装应用可采用非OTA方式进行升级，也即，该预装应用可独立升级。

在本实施例中，车机客户端例如可预先统计出非persistent属性的预装应用，进而可将全部或部分非persistent属性的预装应用作为待升级的第一预装应用。可以理解的是，当待升级的第一预装应用的数量为多个时，该多个待升级的第一预装应用的当前版本信息可同时携带于S101的升级请求信息中，由车机发送至服务器。进一步地，服务器可采用S102中的方法分别确定各个待升级的第一预装应用的目标版本，并可在S103中，将各个待升级的第一预装应用的目标版本的升级包返回给车机端。

在现有的车机预装应用升级方案中，预装应用均通过OTA方式进行升级迭代，但是OTA升级的迭代周期长，且单次升级过程中系统下载文件大，安装时间长，无法实现预装应用的快速灵活升级。与现有技术相比，在本发明实施例中，车机可将一部分可通过非OTA方式进行升级的预装应用分离出来，作为待升级的第一预装应用，进而可将该部分预装应用(待升级的第一预装应用)的当前版本信息携带在升级请求信息，并通过向服务器发送升级请求信息的方式获取该部分预装应用的升级包。也即，该部分预装应用可通过非OTA的方式进行独立升级。如此，能够快速升级该部分预装应用，降低升级成本，提高用户体验，同时能够减少车机的OTA频次。

S102，服务器确定待升级的第一预装应用的目标版本。

其中，待升级的第一预装应用的目标版本，还可以理解为，服务器为车机的第一预装应用所匹配的可用于对该第一预装应用进行升级的升级版本。

示例性地，服务器确定目标版本的方式例如可以为：基于升级请求信息，以及车机的第二预装应用的当前版本信息，确定待升级的第一预装应用的目标版本。其中，目标版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配。该第一预装应用与第二预装应用存在依赖关系，例如，第一预装应用的正常运行依赖于第二预装应用的正常运行。

下面介绍基于升级请求信息，以及车机的第二预装应用的当前版本信息，确定待升级的第一预装应用的目标版本的几种可能的实现方式：

方式1

在方式1中，升级请求信息包括：待升级的第一预装应用的当前版本信息。在该情况下，基于升级请求信息，以及车机的第二预装应用的当前版本信息，确定待升级的第一预装应用的目标版本，可包括以下步骤21)和22)：

21)获取第一预装应用的候选版本集合。

其中，第一预装应用的候选版本集合例如可由服务器中已配置的第一预装应用的各个版本组成。

22)将候选版本集合中满足第一条件的候选版本确定(匹配)为目标版本；其中，第一条件包括以下条件#1。

条件#1：候选版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配。

举例来说，假设待升级的第一预装应用的当前版本为2.0，车机的第二预装应用的当前版本为1.0，那么，若候选集合中存在某个候选版本满足第一条件，即该候选版本大于第一预装应用的当前版本2.0，且能够与1.0版本的第二预装应用适配，那么，则可将该候选版本确定为目标版本。在一些实施例中，当候选集合中存在多个满足第一条件的候选版本时，可将其中版本号最大的候选版本确定为目标版本。在一些实施例中，第一预装应用所依赖的第二预装应用的数量可以为多个。当第二预装应用的数量为多个时，候选版本与车机的第二预装应用的当前版本适配，指的是候选版本与车机上所有第二预装应用的当前版本均适配。

根据本实施例的方法，服务器可从第一预装应用的各个候选版本中，确定出一个版本号大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配的目标版本，从而保证了将第一预装应用升级到目标版本后，该目标版本能够与车机上当前已安装的第二预装应用相适配。

方式2

在方式2中，在方式1的基础上，升级请求信息还包括：车机的车辆识别码，和/或，车机的系统版本信息。在该情况下，第一条件包括上述条件#1，并且还包括以下条件#2。

条件#2：候选版本能够与车机的车辆识别码和/或车机的系统版本适配。

一示例，升级请求信息包括：待升级的第一预装应用的当前版本信息和车机的车辆识别码。在该情况下，第一条件可包括上述条件#1，并且还包括：候选版本能够与车机的车辆识别码适配。也即，确定的目标版本需满足上述条件#1，并且需要与车机的车辆识别码适配。

另一示例，升级请求信息包括：待升级的第一预装应用的当前版本信息和车机的系统版本信息。在该情况下，第一条件可包括上述条件#1，并且还包括：候选版本能够与车机的系统版本适配。也即，确定的目标版本需满足上述条件#1，并且需要与车机的系统版本适配。

又一示例，升级请求信息包括：待升级的第一预装应用的当前版本信息、车机的车辆识别码，以及车机的系统版本信息。在该情况下，第一条件可包括上述条件#1，并且还包括：候选版本能够与车机的车辆识别码适配，并且能够与车机的系统版本适配。也即，确定的目标版本需满足上述条件#1，并且需要同时与车机的车辆识别码和车机的系统版本适配。

根据本实施例的方法，服务器在确定第一预装应用的目标版本的过程中，还可以考虑目标版本与车机的车辆识别码和/或系统版本之间的适配问题，这样，增加了确定目标版本时所依据的参数维度，从而可使得所确定的目标版本的精细化程度更高。

方式3

在方式3中，在方式1的基础上，升级请求信息还包括：待升级的第一预装应用的当前版本所携带的第一参数(如“android:sharedUserId”)。在该情况下，第一条件包括上述条件#1，并且还包括以下条件#3。

条件#3：候选版本携带第一参数。其中，待升级的第一预装应用能够从当前版本成功升级到新版本的条件包括：新版本的第一预装应用携带该第一参数。

也就是说，在方式3中，确定的目标版本需满足上述条件#1，并且该目标版本需携带待升级的第一预装应用的当前版本所携带的第一参数。以第一参数为“android:sharedUserId”为例，若待升级的第一预装应用的当前版本携带“android:sharedUserId”，则确定的目标版本中也需要携带“android:sharedUserId”。

可以理解的是，在第一预装应用的当前版本携带第一参数的情况下，由于要将第一预装应用从当前版本成功升级到新版本，需满足新版本的第一预装应用也携带该第一参数，因此，通过令最终确定出的目标版本携带第一参数，可避免由于第一预装应用的当前版本携带第一参数，而目标版本未携带该第一参数所导致的升级失败。

在一些实施例中，方式3还可以和方式2相结合。也即，升级请求信息可包括：待升级的第一预装应用的当前版本信息、车机的车辆识别码和/或车机的系统版本信息、待升级的第一预装应用的当前版本所携带的第一参数。在该情况下，第一条件可同时包括上述条件#1、条件#2和条件#3。也即，确定的目标版本需同时满足上述条件#1、条件#2和条件#3。

需要说明的是，在上述方式#1至方式3中，当候选集合中存在多个满足第一条件的候选版本时，可将其中版本号最大的候选版本确定为目标版本。

在一些场景中，服务器确定待升级的第一预装应用的目标版本时还可以单独使用上述条件#1、条件#2或条件#3，或者，还可以将任意两个条件结合使用。

一示例，确定待升级的第一预装应用的目标版本时可单独考虑条件#2，此时，若候选版本能够与车机的车辆识别码和/或车机的系统版本适配，即可将该候选版本确定为目标版本。当存在多个满足条件#2的候选版本时，可将其中版本号最大的候选版本确定为目标版本。

另一示例，确定待升级的第一预装应用的目标版本时可同时考虑条件#2和条件#3，此时，若候选版本能够与车机的车辆识别码和/或车机的系统版本适配，并该候选版本携带第一参数，则可将该候选版本确定为目标版本。当存在多个同时满足条件#2和条件#3的候选版本时，可将其中版本号最大的候选版本确定为目标版本。

在一些实施例中，在确定待升级的第一预装应用的目标版本之前，该方法还可以包括：服务器确定各个候选版本可适配的第二预装应用的版本的范围和/或可适配的车机系统版本的范围。

一示例，服务器可确定各个候选版本可适配的第二预装应用的版本的范围(版本区段)。这样，若第二预装应用的当前版本落在某个候选版本可适配的第二预装应用的版本的范围内，则说明该候选版本能够与第二预装应用的当前版本适配。举例来说，假设车机的第二预装应用的当前版本为2.0，某个候选版本可适配的第二预装应用的版本的范围为1.0～3.0，由于2.0落在该范围(区段)内，则说明该候选版本能够与车机的第二预装应用的当前版本适配。

另一示例，服务器可确定各个候选版本可适配的车机系统版本的范围(版本区段)。这样，若车机的系统版本落在某个候选版本可适配的车机系统版本的范围内，则说明该候选版本能够与车机的系统版本适配。举例来说，假设车机的系统版本为3.0，某个候选版本可适配的车机系统版本的范围为1.0～3.0，由于3.0落在该范围(区段)内，则说明该候选版本能够与车机的系统版本适配。

根据本实施例的方法，服务器在确定目标版本之前，可先确定各个候选版本可适配的第二预装应用的版本的范围和/或各个候选版本可适配的车机系统版本的范围，从而可为后续确定目标版本提供参考信息。

在一些实施例中，在确定待升级的第一预装应用的目标版本之前，该方法还可以包括：服务器确定与第一预装应用存在依赖关系的第二预装应用，并获取车机的第二预装应用的当前版本信息。

示例性地，服务器在接收到来自车机的升级请求信息后，可基于后台记录查询第一预装应用所依赖的第二预装应用。进一步地，服务器可查询车机上第二预装应用的当前版本信息。

根据本实施例的方法，服务器可在确定目标版本之前，确定与第一预装应用存在依赖关系的第二预装应用，并可获取车机的第二预装应用的当前版本信息，从而，服务器在确定目标版本的过程中，可将与第一预装应用存在依赖关系的第二预装应用的当前版本信息作为考虑因素之一，以避免升级后的第一预装应用与车机当前的第二预装应用的版本无法适配的问题。

需要说明的是，本发明实施例可为单台车机确定(匹配)第一预装应用的目标版本，以实现单台车机上第一预装应用的升级，或者还可以同时为多台车机确定(匹配)第一预装应用的目标版本，从而实现多台车机上第一预装应用的升级。

S103，服务器向车机发送目标版本的升级包。

相应地，车机可接收来自服务器的目标版本的升级包。其中，该升级包可用于将待升级的第一预装应用从当前版本升级到目标版本。

在一些实施例中，车机在对待升级的第一预装应用进行升级之前，还可以对是否符合升级(更新)规则进行检查。例如，车机可判断目标版本是否大于待升级的第一预装应用的当前版本，若目标版本大于待升级的第一预装应用的当前版本，则说明符合升级规则，在该情况下，可将目标版本显示在车机的应用升级列表中，并显示用于升级第一预装应用的升级选项。若升级选项被选中(如用户点击该升级选项)，则车机可基于升级包，将待升级的第一预装应用从当前版本升级到目标版本。

根据本实施例的方法，车机在对待升级的第一预装应用进行升级之前，可对是否符合升级规则进行检查，若目标版本大于待升级的第一预装应用的当前版本，则说明符合升级规则，进而可将目标版本显示在车机的应用升级列表中，如此，可确保升级的正常进行。

在一些实施例中，在目标版本大于待升级的第一预装应用的当前版本的情况下，车机可判断目标版本是否携带强制更新标签；若目标版本未携带强制更新标签，则显示用于忽略升级第一预装应用的忽略选项，若忽略选项被选中(如用户点击该忽略选项)，则可将目标版本从车机的应用升级列表中删除。

根据本实施例的方法，若目标版本未携带强制更新标签，则可向用户提供忽略升级选项。这样，用户可根据个人需求忽略掉不希望升级的预装应用，从而有利于满足用户的个性化需求。

在一些实施例中，车机例如可通过应用分发方式(如应用商店)对预装应用进行升级，但不限于应用商店。当车机通过应用商店对预装应用进行升级时，应用升级列表可展示在应用商店中。预装应用(如第一预装应用)升级后，即具备升级包中的功能。

在一些实施例中，通过应用商店对预装应用进行升级时，升级包的安装路径不同于预装应用的初始路径，而是与普通非预装应用的安装路径相同，或者为其他路径。例如，预装应用的初始分区(路径)在system下，且预装应用随Rom进行刷写或通过OTA进行升级，用户升级安装完预装应用后，升级之后的预装应用的分区可变更为第三方应用的安装分区，如data/app。

在一些实施例中，预装应用升级安装完成后，还可以提供卸载增量更新功能，预装应用卸载后，功能恢复到system分区下该预装应用的功能，或者说，恢复到OTA中包含的该预装应用的功能。

在一些实施例中，应用商店可扫描系统应用，以区分预装应用和非预装应用，并可显示非预装应用，提供打开和卸载方式。在一些实施例中，应用商店可以为预装应用及非预装应用提供下载、更新、安装功能。

上文结合图1和图2介绍了本发明实施例提供的一种车机中预装应用的升级方法。为便于理解本发明的实施例，下面结合图3介绍本发明实施例提供的车机中预装应用的升级方法的一种可能的实现流程。为简洁，在下文中将预装应用简称为应用。

图3为本发明实施例提供的车机中预装应用的升级方法的一种可能的实现流程示意图，该实现流程例如可由车机端执行。如图3所示，该实现流程可包括：

S301，获取车架号、车机的OS版本和待升级的本地应用信息。

其中，车架号需服务端实际备案，且能够和具体车型对应；OS版本需实际存在，配置应用的服务端可实际选取。

示例性地，本地应用信息可包括：本地应用的当前版本号。在一些实施例中，本地应用信息还可以包括：本地应用的Manifest配置中可影响应用升级的关键参数信息，如“android:sharedUserId”等信息。本实施例中，待升级的本地应用可以为一个或多个，且均为非persistent类型的预装应用。

S302，向服务端发起升级请求，获取应用升级包。

在该步骤中，车机端可使用车架号、车机的OS版本和待升级的本地应用信息，向服务端发起升级请求(对应前述实施例中的升级请求信息)。服务端接收到来自车端的请求后，可根据车架号、车机的OS版本，以及待升级的本地应用信息中的至少一项信息，匹配已配置的预装应用升级包，并返回给车机客户端。

作为一个示例，服务端可基于待升级的本地应用信息，在后台构建应用分布图谱(也即应用之间的依赖关系)。例如，服务端可构建(确定)待升级的本地应用与其他应用之间的依赖关系，从而，服务端可获取待升级的本地应用所依赖的其他应用(例如记为应用A)的信息，如应用A在车机端的当前版本号。进一步地，服务端可基于应用A在车机端的当前版本号、车机的OS版本、待升级的本地应用的当前版本号，为该本地应用匹配一个升级包，且该升级包能够与应用A在车机端的当前版本号以及车机的OS版本适配。

在一些实施例中，若本地应用信息中包含“android:sharedUserId”这一参数，则服务端在为本地应用匹配升级包时，还需满足该升级包的应用信息中同样包含“android:sharedUserId”这一参数。

应理解，当待升级的本地应用为多个时，该步骤可为每个待升级的本地应用分别匹配升级包。

S303，判断是否符合更新规则。

在该步骤中，车机端可扫描本地预装应用，找到与升级包的包名相同的本地应用，并将该本地应用的版本信息与远程版本信息(即升级包中的版本信息)进行对比，检查是否符合更新规则。示例性地，若远程版本的版本号大于本地系统中应用的版本号，则认为符合更新规则。

若S303的判断结果为否，则可执行S304：

S304，丢弃(忽略)升级包。

若S303的判断结果为是，则可将升级包中的应用信息显示在车机的应用升级列表中，并执行S305：

S305，判断升级包是否携带强制更新标签。

其中，该标签信息可由服务端在配置升级包时进行配置。

若S305的判断结果为否，也即，升级包未携带强制更新标签，则可显示忽略按钮，为用户提供主动选择忽略功能。该功能一般适用于非重大功能升级的场景。若S305的判断结果为是，也即，升级包携带有强制更新标签，则不会显示忽略按钮。

S306，检测忽略按钮是否被点击。

若用户点击了忽略按钮，则执行忽略操作，也即，将升级包中的应用信息从应用升级列表中移除。若用户未点击忽略按钮，则升级包中的应用信息仍保留在应用升级列表中。

S307，形成应用升级列表。

其中，应用升级列表可由S305中携带强制更新标签的升级包中的应用信息以及S306中未被忽略的升级包中的应用信息组成，该应用列表中的应用展示为可更新(升级)状态。此时，强制更新的应用仍不可忽略，非强制更新的应用可忽略。

S308，下载应用。

点击“更新(或升级)”按钮后，可下载对应的远程版本安装包，下载过程支持暂停，可断点续传。下载完成后，可校验安装包，若校验失败则结束流程，并提示对应错误，若校验成功则执行S309：

S309，安装应用。

安装包校验成功后，可自动执行安装升级，升级安装成功则可监听安装成功广播，并做对应处理。

根据上述实现流程，本发明实施例的方案可带来以下优势：

1)服务端通过结合车机VIN信息、ROM版本信息及车机当前预装应用的版本号和配置信息，为车机端提供精准的升级方案配置。

鉴于升级应用的情况不同，例如，有的应用升级依赖系统版本，有的应用依赖其他应用版本而不依赖系统版本，有的无依赖或只需针对特定VIN进行升级，为此，本发明实施例可将系统版本、VIN、应用版本(如待升级应用及其依赖的其他应用的版本)这三种维度作为考虑因素，以达到精细化的升级方案配置。和现有技术相比，本发明实施例增加了应用升级时可依据的参数维度，因此应用升级的精细化程度更高。

在一些实施例中，上述三种维度可以还单独使用，或者任意组合使用。也就是说，本发明实施例能够提供针对系统版本、特定VIN或当前车机已安装应用版本信息这三种条件中某一条件的单一控制，或者还可以结合该三种条件进行同时控制。

2)由于应用升级时考虑了待升级应用所依赖的其他应用的版本信息，从而有效规避了升级之后的应用与其所依赖的其他应用不适配的问题。

基于前述的实施例，本发明实施例提供相应的车机中预装应用的升级装置。该装置包括所包括的各模块、以及各模块所包括的各子模块，可以通过具有信息处理能力的计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(Central Processing Unit，CPU)、微处理器(Microprocessor Unit，MPU)、数字信号处理器(Digital Signal Processor，DSP)或现场可编程门阵列(FieldProgrammable Gate Array，FPGA)等。

图4示出了本发明实施例提供的一种车机中预装应用的升级装置400(下文中简称为装置400)的组成结构。如图4所示，装置400可以包括：

第一接收单元401，用于接收来自车机的升级请求信息，升级请求信息包括：待升级的第一预装应用的当前版本信息；第一确定单元402，用于基于升级请求信息，以及车机的第二预装应用的当前版本信息，确定待升级的第一预装应用的目标版本；其中，目标版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配；第一预装应用与第二预装应用存在依赖关系；第一发送单元403，用于向车机发送目标版本的升级包，升级包用于将待升级的第一预装应用从当前版本升级到目标版本。

在一些实施例中，第一确定单元402，具体用于：获取第一预装应用的候选版本集合；将候选版本集合中满足第一条件的候选版本确定为目标版本；其中，第一条件包括：候选版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配。

在一些实施例中，升级请求信息还包括：车机的车辆识别码，和/或，车机的系统版本信息；第一条件还包括：候选版本能够与车机的车辆识别码和/或车机的系统版本适配。

在一些实施例中，升级请求信息还包括：待升级的第一预装应用的当前版本所携带的第一参数；其中，待升级的第一预装应用能够从当前版本成功升级到新版本的条件包括：新版本的第一预装应用携带该第一参数；第一条件还包括：候选版本携带该第一参数。

在一些实施例中，装置400还包括：第二确定单元，用于在确定待升级的第一预装应用的目标版本之前，确定各个候选版本可适配的第二预装应用的版本的范围和/或可适配的车机系统版本的范围。

在一些实施例中，装置400还包括：第三确定单元，用于在确定待升级的第一预装应用的目标版本之前，确定与第一预装应用存在依赖关系的第二预装应用；获取单元，用于获取车机的第二预装应用的当前版本信息。

图5示出了本发明实施例提供的另一种车机中预装应用的升级装置500(下文中简称为装置500)的组成结构。如图5所示，装置500可以包括：

第二发送单元501，用于向服务器发送升级请求信息，升级请求信息包括：待升级的第一预装应用的当前版本信息；第二接收单元502，用于接收来自服务器的第一预装应用的目标版本的升级包，升级包用于将待升级的第一预装应用从当前版本升级到目标版本；其中，目标版本是由服务器基于升级请求信息，以及车机的第二预装应用的当前版本信息确定的；其中，目标版本大于待升级的第一预装应用的当前版本，且与车机的第二预装应用的当前版本适配；第一预装应用与第二预装应用存在依赖关系。

在一些实施例中，装置500还包括：第一判断单元，用于判断目标版本是否大于待升级的第一预装应用的当前版本；第一显示单元，用于若目标版本大于待升级的第一预装应用的当前版本，则将目标版本显示在车机的应用升级列表中，并显示用于升级第一预装应用的升级选项；升级单元，用于若升级选项被选中，则基于升级包，将待升级的第一预装应用从当前版本升级到目标版本。

在一些实施例中，装置500还包括：第二判断单元，用于在目标版本大于待升级的第一预装应用的当前版本的情况下，判断目标版本是否携带强制更新标签；第二显示单元，用于若目标版本未携带强制更新标签，则显示用于忽略升级第一预装应用的忽略选项；删除单元，用于若忽略选项被选中，则将目标版本从车机的应用升级列表中删除。

在一些实施例中，装置500还包括：确定单元，用于在向服务器发送升级请求信息之前，将车机中可通过非空中下载方式进行升级的待升级预装应用确定为待升级的第一预装应用。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。在一些实施例中，本发明实施例提供的装置具有的功能或包含的模块可以用于执行上述方法实施例描述的方法，对于本发明装置实施例中未披露的技术细节，请参照本发明方法实施例的描述而理解。

需要说明的是，本发明实施例中，如果以软件功能模块的形式实现上述的方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本发明实施例不限制于任何特定的硬件、软件或固件，或者硬件、软件、固件三者之间的任意结合。

本发明实施例还提供一种车机中预装应用的升级设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的部分或全部步骤。

本发明实施例还提供一种芯片。该芯片包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有该芯片的设备执行上述方法中的部分或全部步骤。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的部分或全部步骤。所述计算机可读存储介质可以是瞬时性的，也可以是非瞬时性的。

本发明实施例还提供一种计算机程序，包括计算机可读代码，在所述计算机可读代码在设备(如车机中预装应用的升级设备)中运行的情况下，所述设备中的处理器执行上述方法中的部分或全部步骤。

本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序被计算机读取并执行时，实现上述方法中的部分或全部步骤。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一些实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一些实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

这里需要指出的是：上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考。以上设备、芯片、存储介质、计算机程序及计算机程序产品实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本发明设备、存储介质、计算机程序及计算机程序产品实施例中未披露的技术细节，请参照本发明方法实施例的描述而理解。

图6为本发明实施例中车机中预装应用的升级设备的一种硬件实体示意图。图6所示的车机中预装应用的升级设备600(下文中简称为设备600)包括处理器610，处理器610可以从存储器中调用并运行计算机程序，以实现本发明实施例中的方法。

在一些实施例中，如图6所示，设备600还可以包括存储器620。其中，处理器610可以从存储器620中调用并运行计算机程序，以实现本发明实施例中的方法。其中，存储器620可以是独立于处理器610的一个单独的器件，也可以集成在处理器610中。

在一些实施例中，如图6所示，设备600还可以包括收发器630，处理器610可以控制该收发器630与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。其中，收发器630可以包括发射机和接收机。收发器630还可以进一步包括天线，天线的数量可以为一个或多个。

在一些实施例中，该设备600具体可为本发明实施例的服务器，并且该设备600可以实现本发明实施例的各个方法中由服务器实现的相应流程，为了简洁，在此不再赘述。

在一些实施例中，该设备600具体可为本发明实施例的车机，并且该设备600可以实现本发明实施例的各个方法中由车机实现的相应流程，为了简洁，在此不再赘述。

应理解，说明书通篇中提到的“一个实施例”、“一实施例”或“一些实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”、“在一实施例中”或“在一些实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本发明的各种实施例中，上述各步骤/过程的序号的大小并不意味着执行顺序的先后，各步骤/过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本发明所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元或模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。