一种应用显示接续方法及装置转让专利

申请号 : CN202010203441.7

文献号 : CN111447323B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 高曦张帮明黄浩

申请人 : 华为技术有限公司

摘要 :

本申请实施例涉及一种应用显示接续方法,方法应用于终端设备,终端设备与车载设备通过有线或无线相连接,终端设备上运行着第一应用和至少一个第二应用,方法包括:第一应用发送第一广播到至少一个第二应用,以便至少一个第二应用根据第一广播发送第二广播;接收至少一个第二应用发送的第二广播,其中,第二广播包括第二应用的第一数据信息;根据第一数据信息,生成第二应用所对应的卡片并在车载设备上进行展示;当用户点击第二应用所对应的卡片时,结合第二应用的第一数据信息,将第二应用的内容在车载设备上进行显示。实现多种不同应用的同时接续。继承了原有手机界面,从而不用改变用户习惯,并大大提升了在车载设备上操作不同应用的便捷性。

权利要求 :

1.一种应用显示接续方法,所述方法应用于终端设备,所述终端设备上运行着第一应用、第二应用、第三应用,其特征在于,所述方法包括:当所述终端设备与车载设备连接后,所述第一应用发送第一广播;

第二应用收到所述第一广播后,发送所述第二应用的第一数据信息给所述第一应用;

第三应用收到所述第一广播后,发送所述第三应用的第一数据信息给所述第一应用;

第一应用根据所述第二应用的第一数据信息和所述第三应用的第一数据,生成待显示界面,所述待显示界面上包括第二应用对应的卡片和第三应用 对应的卡片,所述第二应用的卡片基于所述第二应用的第一数据信息生成,所述第三应用的卡片基于所述第三应用的第一数据信息生成;

所述终端设备将所述待显示界面发送给所述车载设备显示。

2.如权利要求1所述的方法,其特征在于,所述方法还包括:当所述第二应用的卡片添加在待显示界面上,所述第一应用通知所述第二应用以告知所述第二应用的卡片添加成功;

当所述第三应用的卡片添加在待显示界面上,所述第一应用通知所述第三应用以告知所述第三应用的卡片添加成功。

3.如权利要求1所述的方法,其特征在于,所述方法还包括:所述第二应用发送所述第二应用的第二数据信息给所述第一应用;

所述第一应用根据所述第二应用的第二数据信息,更新所述第二应用的卡片。

4.如权利要求1所述的方法,其特征在于,所述方法还包括:所述第一应用接收所述第二应用发送的移除消息;

根据所述移除消息,移除在所述车载设备上显示的所述第二应用的卡片。

5.如权利要求1所述的方法,其特征在于,所述方法还包括:当所述终端设备与车载设备断开连接时,所述第一应用分别发送移除通知给所述第二应用和第三应用,以告知所述第二应用的卡片和所述第三应用的卡片被移除。

6.如权利要求1所述的方法,其特征在于,所述方法还包括:当所述终端设备与车载设备断开连接时,所述第一应用发送第二广播,以告知所述第二应用和所述第三应用所述终端设备与车载设备之间的连接已经断开。

7.如权利要求4所述的方法,其特征在于,所述第二应用的第一数据信息包括:所述第二应用的卡片的卡片标识、所述第二应用的内容,以及所述第二应用的包名、所述第二应用的卡片的卡片类型、所述第二应用的卡片的优先级中的一个或多个。

8.如权利要求7所述的方法,其特征在于,所述移除消息包括:所述第二应用所的所述卡片的卡片标识。

9.一种终端设备,其特征在于,所述终端设备包括:处理器,用于与存储器耦合,以及读取并执行所述存储器中的指令;

当所述处理器运行时执行所述指令,使得所述终端设备执行权利要求1‑8任一项所述的方法。

10.一种计算机可读存储介质,所述计算机可读存储介质中存储有指令,其特征在于,当所述指令在终端上运行时,使得所述终端执行如权利要求1‑8任意一项所述的方法。

说明书 :

一种应用显示接续方法及装置

技术领域

[0001] 本申请涉及车载领域,尤其涉及一种在车机互联场景下的应用显示接续方法及装置。

背景技术

[0002] 在当今社会,随着手机技术和连接技术的发展,人们在驾驶时使用手机的情况也变得愈发普遍。绝大多数情况下,用户在驾驶时使用手机通常可能包括导航、打电话、进行
媒体播放或听音乐等多种场景。在驾驶时使用手机的场景中,导航使用频率最高,其次是在
驾驶时接通电话。而使用频率较高的还包括听音乐以及主动拨通电话等。并且在驾驶时使
用手机的情况下,绝大部分用户会选择使用蓝牙或者车载辅助(auxiliary,AUS)接口等方
式将手机与汽车进行连接,以便将手机和车载设备进行协同使用。仅有少数用户选择了独
立使用手机或者独立使用车载设备。可见在日常生活中,驾驶时使用手机并且将手机与车
载设备相连接变得非常普遍。
[0003] 在车机连接的场景下,一个非常关键的使用场景就是应用接续。应用接续即一个应用在正在使用的状态下,从用户的终端设备上切换至车载设备上,并且保持应用的正常
使用不会因为切换使用设备而发生中断,包括显示接续、音频继续等,其中显示接续可以保
持应用上显示的内容从终端设备切换至车载设备显示时不中断,音频继续可以保持应用的
音频在从终端设备切换至车载设备播放时不中断。该终端设备并不包括车载设备。当用户
在手机上进行导航、语音通话或是看音频、视频的时候,若此时正好将手机与车载设备相连
接,应用切换至车载设备的车载屏后,如何保证能够时应用程序继续播放或继续导航,是一
个非常重要的研究方向。但在现有的方案中仅仅只能做出非常有限的几个应用的接续。对
于其他更多的应用则在车机连接的过程中,无法实现应用的接续。

发明内容

[0004] 本申请实施例提供了一种应用显示接续方法及装置。可以实现对多个第三方应用从终端设备到车载设备上的显示接续,符合用户使用的连续性,便于用户的使用。
[0005] 第一方面,提供了一种应用显示接续方法,方法应用于终端设备,终端设备与车载设备通过有线或无线相连接,终端设备上运行着第一应用和至少一个第二应用,方法包括:
第一应用发送第一广播到至少一个第二应用,以便至少一个第二应用根据第一广播发送第
二广播;接收至少一个第二应用发送的第二广播,其中,第二广播包括第二应用的第一数据
信息;根据第一数据信息,生成第二应用所对应的卡片并在车载设备上进行展示;当用户点
击第二应用所对应的卡片时,结合第二应用的第一数据信息,将第二应用的内容在车载设
备上进行显示。
[0006] 在一个可能的实施方式中,方法还包括:第一应用发送至少一个第三广播到至少一个第二应用,以告知至少一个第二应用卡片添加成功。
[0007] 在一个可能的实施方式中,方法还包括:接收至少一个第二应用发送的至少一个第四广播,其中,第四广播包括第二应用的第二数据信息;根据第二应用的第二数据信息,
更新在车载设备上显示的第二应用的内容。
[0008] 在一个可能的实施方式中,方法还包括:接收至少一个第二应用发送的至少一个第五广播,其中,第五广播包括第二应用的第三数据信息;根据第二应用的第三数据信息,
移除在车载设备上显示的第二应用所对应的卡片。
[0009] 在一个可能的实施方式中,方法还包括:当终端设备与车载设备断开连接时,第一应用发送至少一个第六广播到至少一个第二应用,以告知至少一个第二应用所对应的卡片
被移除。
[0010] 在一个可能的实施方式中,方法还包括:发送第七广播到至少一个第二应用,以告知至少一个第二应用终端设备与车载设备之间的有线连接或无线连接已经断开。
[0011] 在一个可能的实施方式中,第一数据信息和第二数据信息包括:第二应用所对应卡片的卡片标识、第二应用的包名、第二应用所对应卡片的卡片类型、第二应用所对应的卡
片的优先级和第二应用的内容中的一个或多个。
[0012] 在一个可能的实施方式中,第三数据信息包括:第二应用所对应卡片的卡片标识和第二应用的包名中的一个或多个。
[0013] 第二方面,提供了一种应用显示接续的方式,所述方法应用于终端设备,所述终端设备上运行着第一应用、第二应用、第三应用,所述方法包括:当所述终端设备与车载设备
连接后,所述第一应用发送第一广播;第二应用收到所述第一广播后,发送所述第二应用的
第一数据信息给所述第一应用;第三应用收到所述第一广播后,发送所述第三应用的第一
数据信息给所述第一应用;第一应用根据所述第二应用的第一数据信息和所述第三应用的
第一数据,生成待显示界面,所述待显示界面上包括第二应用对应的卡片和第三对应的卡
片,所述第二应用的卡片基于所述第二应用的第一数据信息生成,所述第三应用的卡片基
于所述第三应用的第一数据信息生成;所述终端设备将所述待显示界面发送给所述车载设
备显示。
[0014] 在一个可能的实施方式中,所述方法还包括:所述第二应用的卡片添加在待显示界面上,所述第一应用通知所述第二应用以告知所述第二应用的卡片添加成功;当所述第
三应用的卡片添加在待显示界面上,所述第一应用通知所述第三应用以告知所述第三应用
的卡片添加成功。
[0015] 在一个可能的实施方式中,所述方法还包括:所述第二应用发送所述第二应用的第二数据信息给所述第一应用;所述第一应用根据所述第二应用的第二数据信息,更新所
述第二应用的卡片。
[0016] 在一个可能的实施方式中,所述方法还包括:所述第一应用接收所述第二应用发送的移除消息;根据所述移除消息,移除在所述车载设备上显示的所述第二应用的卡片。
[0017] 在一个可能的实施方式中,所述方法还包括:当所述终端设备与车载设备断开连接时,所述第一应用分别发送移除通知给所述第二应用和第三应用,以告知所述第二应用
的卡片和所述第三应用的卡片被移除。
[0018] 在一个可能的实施方式中,所述方法还包括:当所述终端设备与车载设备断开连接时,所述第一应用发送第二广播,以告知所述第二应用和所述第三应用所述终端设备与
车载设备之间的连接已经断开。
[0019] 在一个可能的实施方式中,所述第二应用的第一数据信息包括:所述第二应用的卡片的卡片标识、所述第二应用的内容,以及所述第二应用的包名、所述第二应用的卡片的
卡片类型、所述第二应用的卡片的优先级中的一个或多个。
[0020] 在一个可能的实施方式中,所述移除消息包括:所述第二应用所的所述卡片的卡片标识。
[0021] 第三方面,提供了一种终端设备,终端设备与车载设备相连接,终端设备上运行着第一应用和至少一个第二应用,终端设备包括:处理器,用于与存储器耦合,以及读取并执
行存储器中的指令;当处理器运行时执行指令,使得所述终端设备执行上述第一方面和第
二方面,以及每一可能的实施方式中的任意一种方法。
[0022] 第四方面,提供了一种计算机可读存储介质,计算机可读存储介质中存储有指令,当指令在终端上运行时,使得终端执行上述第一方面和第二方面,以及每一可能的实施方
式中的任意一种方法。
[0023] 第五方面,提供了一种包含指令的计算机程序设备,当其在终端上运行时,使得终端执行上述第一方面和第二方面,以及每一可能的实施方式中的任意一种方法。
[0024] 本申请公开了一种应用显示接续方法及终端设备,当终端设备与车载设备连接后,通过终端车载应用与第三应用之间发送广播,从而将第三方应用以卡片的形式展示在
车载设备的显示屏上,从而实现多种不同的第三方应用的同时接续。继承了原有手机界面,
从而不用改变用户习惯,并且由于能够实现任意种类、任意数量的应用同时接续,从而大大
提升了在车载设备上操作不同应用的便捷性。

附图说明

[0025] 图1为本申请实施例提供的一种场景示意图;
[0026] 图2为本申请实施例提供的一种应用显示接续框架示意图;
[0027] 图3为本申请实施例提供的另一种应用显示接续框架示意图;
[0028] 图4为本申请实施例提供的一种应用显示接续的信息交互图;
[0029] 图5为本申请实施例提供的一种终端设备与车载设备连接示意图;
[0030] 图6为本申请实施例提供的一种车载屏卡片显示示意图;
[0031] 图7为本申请实施例提供的一种应用接续效果示意图;
[0032] 图8为本申请实施例提供的另一种应用接续效果示意图;
[0033] 图9为本申请实施例提供的一种应用显示接续方法流程图;
[0034] 图10为本申请实施例提供的另一种应用显示接续方法流程图;
[0035] 图11为本申请实施例提供的又一种应用显示接续方法流程图;
[0036] 图12为本申请实施例提供的再一种应用显示接续方法流程图;
[0037] 图13为本申请实施例提供的一种终端设备示意图。

具体实施方式

[0038] 下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。
[0039] 本申请主要应用在用户驾驶车辆时使用手机上应用的场景,例如图1示出的一种场景示意图。由图1可以看出在车载环境中,车载设备100具有显示屏101,在该场景下当用
户位于车载环境中使用终端设备时,可以通过终端设备与车载设备进行连接,以便在车载
设备的显示屏上显示终端设备上运行的各种应用。本申请可以将手机上的应用 
(application,APP)在终端设备连接至车载设备后实现快速接续,并保障例如通话、导航、
多媒体播放等一系列功能可以继续使用,从而提高车机交互的连续性并提升用户体验。其
中,手机上的APP可以包括第三方APP,或是一些手机厂家自研的APP。可以理解的是,对于自
研的APP或第三方APP,可以是能与用户实现交互的应用,例如音乐、视频、地图等。本申请所
指代的交互,即APP在使用过程中为满足使用需求与用户进行的互动。当然,类似设置、应用
商城等APP与用户的交互,可以通过系统设置的白名单或黑名单,选择性不实现接续,即设
置等APP不会在车载设备的显示屏上显示。当然手机上还有一些不与用户交互的APP,这类
APP一般不需要在车载设备的显示屏上显示,所以以下实施例中以需要显示的APP为例。
[0040] 在一些方案中,仅仅支持简单的导航接续、通话接续。然而,例如导航接续为针对车载屏(即车载设备的显示屏)的定制接续,这类定制接续只能支持固定应用的接续。而对
于另外一些应用,由于安卓系统中并未给这些APP创建相应的活动(activity)生命周期,使
得不同的应用需要单独定制适配,才可以在车载屏上进行有限的某几个界面的接续。显然
该方案中只能做到非常有限的应用接续。相对来讲,由于车载设备的系统较为封闭,使得无
法灵活应对终端设备上的各种应用的接续。该方案中对于可以接续的应用也仅仅做到了单
个应用的接续,无法做到多个应用同时接续,例如音乐、导航、通话等应用。
[0041] 本申请的终端设备与车载设备进行连接后,例如图2示出的一种应用显示接续框架示意图。当终端设备201与车载设备202相连接后,终端设备201的系统框架层2013,将会
发送S201第一消息至车载APP,通知车载APP 2012终端设备201和车载设备202连接。车载
APP 2012接收到第一消息后,开始创建待显示桌面,并且发送第二消息至一个或多个其它
APP 2011(接续APP),第二消息用于通知接续APP提供自身的数据信息,这些数据信息可以
用于绘制显示界面,实现显示接续,第二消息可以以广播的方式群发,终端设备中正在运行
的APP可以收到第二消息,这些运行中的APP可以都是接续APP,可以根据预先设置的,运行
的APP中的一些是接续APP,一些不是接续APP,接续APP收到第二消息后会提供自身的数据
信息义工接续,不是接续APP的APP收到第二消息后会忽略第二消息,不做处理。可以理解的
是本申请所涉及的接续APP2011为可以安装在终端设备201上的除车载APP 2012以外的其
它任意一款APP,可以是能与用户进行交互的APP,例如导航地图20111、音乐20112、语音通
话20113、视频会议20114以及视频通话20115 等应用。当然,对于类似设置、应用商城等
APP,可以通过设置白名单或者黑名单的方式,选择终端设备的此类APP不在车载设备上接
续的APP。接续APP2011在接收到第二消息后,将包含自身APP数据信息的第三消息发送至车
载APP(S203)。车载APP 2012根据一个或多个接续APP2011发送的第三消息,绘制车载屏的
待显示桌面,其中绘制的待显示桌面中包含有一个或多个接续APP2011对应的信息,比如卡
片,图标等。然后车载APP 2012 可以通知系统框架层2013接续APP2011的进程开启(S204),
以便系统框架层2013对接续 APP进行进程管理。终端设备将包含绘制完成的待显示桌面的
信息发送至车载设备202,并车载设备202收到后进行渲染和显示。
[0042] 当然,接续APP2011还可以发送更新消息,例如更新消息中可以携带接续APP2011 更新的信息,以便车载APP 2012在接收到更新消息后,根据更新消息对待显示桌面中相应
的接续APP2011的信息进行更新。若接续APP2011关闭后,则还可以发送移除消息至车载APP 
2012。车载APP 2012根据接收到的移除消息,移除待显示桌面中相应的其他APP 2011的信
息。可以理解的是,若车载设备202与终端设备201断开连接后,则车载APP 2012 可以停止
提供待显示桌面给车载设备。应用接续中除了显示接续还有音频接续等,音频接续可以采
用现有技术中的接续方式。
[0043] 下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行详细描述。
[0044] 为方便描述,本申请将以终端设备运行安卓系统为例对本方案进行详细的描述,通过基于安卓(android)的投屏技术,将不同的接续应用以卡片或表格等形式,实现在车载
设备上进行展示,并同时支持多个不同接续应用同时接续。当然,终端设备上运行的操作系
统还可以包括但不限于搭载iOS、microsoft或者其他操作系统的便携式终端设备。本申请
实施例对此不作具体限定。
[0045] 本申请涉及的方案主要应用在终端设备上,其中,终端设备可以但不限于手机、可穿戴设备、平板电脑、个人数字助理(personal digitalassistant,PDA)、膝上型计算机
(laptop)、移动电脑等任意终端设备或便携式终端设备。如图3示出的,本申请提供了另一
种应用显示接续框架的示意图。
[0046] 从图3中可以看出,位于终端设备中的接续应用(接续APP)301与终端车载APP 302 可以通过广播进行交互。其中,接续应用301即指代图2中的其它APP 2011。可以理解的是接
续应用301可以是第三方APP或非第三方APP,接续应用301是可以与用户进行互动的APP,终
端车载APP 302即指代图2中终端设备201上运行的车载APP 2012。系统框架(framework)层
2013与图2中的系统框架2013相同,具有负责监控终端设备与车载设备之间连接情况的连
接管理20131、虚拟屏幕创建、外屏生命周期管理、进程管理20132 等功能。其中,进程管理
20132用于管理接续应用进程的关闭或拉起等。通过连接管理20131 识别出终端设备与车
载设备相连接之后,生成显示添加(displayadd)消息(S301),发送给终端车载APP 302,以
使得终端车载APP302准备待显示界面。本领域人员应当注意, framework层为终端设备的
framework层,同时也可以与该终端设备上的其它任意APP进行交互。
[0047] 终端车载APP 302可以包含用户界面(system user interface,systemUI)模块,用于负责车载设备的车载屏上显示的程序坞(dock)栏、状态栏以及桌面启动器(launcher)
等视图(view)绘制,例如图6中除了卡片以外的内容的绘制。终端车载APP通过发送启动 
(start)广播告知一个或多个接续应用301(S302),此时车载设备已经开启,以便接续应用
301将相应信息通过广播的形式发送至终端车载APP 302(S303)。其中,对于接续应用301发
送的相应信息,可以是文本数据、图标数据或是卡片数据。终端车载APP 302 在接收到一个
或多个接续应用301发送的相应数据后,生成车载屏的待显示界面。例如若相应数据为纯文
本数据,则可以通过表格的形式展示;若相应数据为图标数据,则可以通过图标的形式展
示;若相应数据为卡片数据,则可以通过卡片的形式展示。对于卡片形式,还可以对多个卡
片的生命周期进行管理。若某个文本框、图标或卡片被选中启动时,则反馈至终端设备的
framework层2013进行进程管理。
[0048] 当在手机上运行的任意除终端车载APP以外的其它APP监听到终端车载APP 302发送的start广播后,发送相应的信息,同时还可以通过广播接续应用301相应的更新信息进
行接续。可以理解的是,当接续应用301已经启动运行时,才可能监听到start广播。当然,对
于类似设置、应用商城等APP,由于并不需要用户实现相应接续,因此即使此类APP 启动运
行后,在监听到广播后时可以忽略start广播。在一个例子中,通过设置白名单或者黑名单
的方式,选择终端设备的哪些APP在监听到start广播后进行响应,并发送APP相应的信息。
[0049] 图4为本申请实施例提供的一种应用显示接续的信息交互图。
[0050] 如图4所示,公开了一种应用显示接续的信息交互示意图,图4中包括有framework 层、终端车载APP和第三方APP三部分。在一个例子中,终端车载APP可以包括终端车载
systemUI、广播发送器(broadcast sender)和远程卡片接收器(remote card receiver)。
[0051] 本领域技术人员应当注意的是,本申请所涉及的车载设备是具有车载屏的车载设备,终端设备可以通过有线或无线的链接方式将终端设备的画面迁移至车载设备的车载屏
上进行显示,例如图5示出的。
[0052] 在一个实施例中,首先需要将终端设备与车载设备通过有线或者无线进行连接,例如图5所示。可以看出终端设备需要通过进行有线连接或者无线连接与车载设备的车载
屏进行连接以便将终端设备上的信息发送至车载设备的车载屏上进行显示。在一个例子
中,终端设备上运行着终端车载应用以及一个或多个第三方APP/非第三方APP(接续APP)。
在终端设备与车载设备相连接以后,终端设备的framework层接收到一个指示(S401),该指
示例如可以是添加显示(add display,add display为软件的指令或代码,以下类似),用于
指示framework层进行创建显示(create display)(S402)。其中,create display用于创建
在车载设备显示屏上显示的待显示桌面。然后framework层通知终端车载systemUI进行添
加显示(S403),例如通知消息是启动服务(bindService()),用于指示终端车载systemUI 
启动相应服务进行添加显示。当终端车载systemUI接收到bindService()后将会创建初始
的车载显示屏界面(S404),例如包括添加导航栏、添加状态栏以及添加桌面启动器等。终端
车载systemUI通过上述步骤生成了初始的车载屏显示界面,之后终端车载systemUI 调用
启动函数(S405),例如onStart(),以便通过广播发送器(broadcast sender)发送第一广
播至第三方APP/非第三方APP(S406)。
[0053] 终端车载APP与第三方APP/非第三方APP主要通过广播机制进行状态以及数据的交互,第三方APP/非第三方APP可以通过适配终端车载APP提供的广播机制,从而实现将第
三方APP/非第三方APP从终端设备的显示屏接续到车载设备的车载屏上,并进行数据传递。
在一个例子中,S406中的第一广播可以是ACTION_CAR_STARTED,该广播的发送方为终端车
载端APP,作为接收方可以是在终端设备上运行的任意APP,第一广播用于指示终端设备与
车载设备已连接。可以理解的是,在发送第一广播的时候,终端车载端 APP将该广播进行群
发,以便正在运行的APP都可以收到第一广播,并发送第二广播至终端车载端APP。可以理解
的是,第一广播通知正在运行的第三方APP/非第三方APP车载设备已经连接完成,可以开始
进行数据交互。该第一广播并不具有额外数据,可以作为单纯的消息广播。
[0054] 当至少一个第三方APP/非第三方APP接收到第一广播以后,可以进行发送第二广播至终端车载APP(S407)。在一个例子中,可以是远程卡片接收器(remote card receiver) 
接收第二广播。可以理解的是,远程卡片接收器RemoteCardReceiver接收的第二广播可以
是一个,也可以是多个,具体取决于有多少个的第三方APP/非第三方APP发送各自对应的第
二广播。其中,第二广播可以是ACTION_APP_REMOTE_CARD_ADD,该广播的发送方为第三方
APP/非第三方APP,该广播中可以携带有第三方APP/非第三方APP需要显示的信息。显然,终
端车载APP是接收方。第三方APP/非第三方APP在接收到终端车载 APP发送的第一广播消息
后,发送包含自身信息的广播至终端车载APP,以便终端车载 APP进行添加远程信息,如在
车载设备的待显示桌面上绘制该第三方APP/非第三方APP 对应的信息。其中,对应的信息
可以通过表格、图标或卡片等形式进行展示。该第二广播包含了第三方APP/非第三方APP对
应的基本信息,例如包名、标识等;以及需要显示的信息,例如应用数据等。当
RemoteCardReceiver接收到至少一个第二广播后,通知终端车载systemUI进行添加远程卡
片(S408),可以理解地,S408中远程卡片接收器 (RemoteCardReceiver)将第二广播的信息
转发给终端车载systemUI。
[0055] 在一个例子中,终端车载APP还可以通过广播发送器BroadcastSender发送第三广播至第三方APP/非第三方APP(S409)。其中,第三广播可以是ACTION_APP_REMOTE_ CARD_
ADDED,该广播的发送方为终端车载APP,该广播中可以指示第三方APP/非第三方APP的对应
的信息已添加到待显示界面。一个第三广播的接收方是一个第三方APP/非第三方APP,第三
广播并不是如第一广播那样进行群发。可以理解的是,针对不同的第三方APP/非第三方
APP,终端车载APP通过在第三广播中携带用于指示特定APP的信息发送不同的第三广播到
对应的第三方APP/非第三方APP。其中,终端车载APP发送的第三广播可以作为一种响应消
息,用于表示第三方APP或非第三方APP对应的信息在终端车载APP的待显示桌面上添加成
功。可以理解的是,第三广播用于终端车载APP反馈信息添加成功消息至对应的第三方APP/
非第三方APP。若在终端车载APP上以卡片形式展示,则该第三广播还包含有卡片对应的卡
片标识,当具有多个卡片时用于区分不同的卡片。例如导航应用和音乐播放应用都收到了
群发的第一广播后,各自发送自己的第二广播给终端车载APP,当终端车载APP在车载屏的
待显示界面上根据导航应用的第二广播添加了导航应用对应的卡片后,发送第三广播给导
航应用通知导航应用卡片添加成功,当终端车载A PP在车载屏的待显示界面上根据音乐播
放应用的第二广播添加了导航应用对应的卡片后,发送第三广播给音乐播放应用通知音乐
播放应用卡片添加成功。
[0056] 在一个例子中,终端车载APP与第三方APP或非第三方APP之间通过第一广播、第二广播以及第三广播,实现了在终端设备与车载设备相连接后,终端车载APP在待显示桌面上
加载第三方APP或非第三方APP相应信息的过程。其中,该待显示桌面用于在车载设备的车
载屏上显示。
[0057] 在一些例子中,添加第三方APP或非第三方APP只有在终端设备与车载设备刚开始连接的时候进行添加,也就是仅在终端设备和车载设备刚连接时发送第一广播,因此只有
收到过第一广播的第三方APP或非第三方APP发送的第二广播进行添加卡片。例如若终端设
备为手机,在手机与车载设备连接之前,手机上同时运行着5个应用,如应用A、B、 C、D、E。则
在手机与车载设备连接后,也将生成应用A、B、C、D、E各自对应的信息,例如表格、图标或卡
片。但若连接后手机又打开了新的应用如应用F,则此时不再生成应用F对应的信息。当然在
另一些例子中,若用户在车载设备的车载屏上,通过特定操作由某个应用返回桌面时,可以
使得终端车载APP重复上述发送第一广播的步骤,并重新接收新的第二广播,以便重新绘制
待显示桌面,从而保障了待显示桌面上应用种类或数量上的更新。例如,车载屏上正在显示
某个APP,当用户点返回按钮后,车载屏上显示的画面由某个APP变为桌面。此时可以通过可
以重复上述第一广播至第三广播,重新绘制待显示桌面,以保障在使用某个APP期间,用户
在终端设备上又新打开了应用F,可以将应用F所对应的信息在待显示桌面上进行显示。例
如,表格中增加新的应用F,或是增加新的图标 F,又或是新添加应用F的卡片。
[0058] 在一个实施例中,第二广播中携带有第三方APP/非第三方APP对应的信息。在一个例子中信息可以是文本信息,或是图标信息,又或是卡片信息。其中,以卡片信息为例,该卡
片信息的信息格式可以如表1所示,
[0059] 表1
[0060]关键字(key) 类型 描述
cardID IntExtra 卡片唯一标识
packageName StringExtra 三方APP包名,生成卡片标题
cardType IntExtra 卡片类型
priority IntExtra 排序优先级
remoteViews ParcelableExtra 卡片内容
[0061] Android提供了意图(intent)机制来协助应用间的交互与通讯,而上述表1示出的卡片信息格式则提供了一种较为具体的广播intent内容。
[0062] 其中,该广播格式可以包括卡片标识(cardidentity,cardID),其数据类型为整型IntExtra,用于表示卡片的唯一标识;包名(package name)表示第三方APP/非第三方APP的
包名,其数据类型为字符串StringExtra,可以用于生成卡片的标题,例如音乐、通话、地图
等名称;卡片类型(card type)其数据类型为整型IntExtra,用于表示卡片对应应用的类
型,例如通知类、按钮类或是实时刷新类等;优先级(priority)其数据类型为整型
IntExtra,用于表示该卡片在车载设备的车载屏上显示的优先顺序,例如优先级高的卡片
优先进行显示;远程视图(remot view)其数据类型为复杂数据类型ParcelableExtra,用于
表示该卡片所需要展示的所有内容,例如音乐数据、视频数据、通话数据、地图数据等,比如
音频播放器的界面的内容,视频播放器的界面的内容,通话界面的内容,导航界面的内容。
在一个例子中,上述cardType中的通知类可以表示该卡片对应的应用可以是日程信息类的
应用;按钮类可以表示该卡片对应的应用可以是语音通话、音乐、视频等应用;实时刷新类
可以表示该卡片对应的应用可以是地图导航、观星等应用。可以理解地,至少包括卡片内
容,卡片标识,卡片标识可以替换为包名。
[0063] 当然可以理解的是,当待车载设备显示的第三方APP/非第三方APP对应的信息为文本信息,或是图标信息,则可以无需cardID以及cardType。对于图标信息则可以包含图标 
ID以及图标Type等任意可能需要的相关信息。
[0064] 下面继续回到图4,当终端车载APP生成的第三方APP/非第三方APP对应的信息,其内容需要进行更新的时候,可以进行S410,如第三方APP或非第三方APP将发送第四广播至
终端车载APP,终端车载APP中的RemoteCardReceiver接收第四广播。可以理解的是,该第四
广播与第二广播类似,可以是一个或多个,具体取决于有多少个不同的第三方APP/非第三
方APP需要对自身对应的卡片进行更新并发送各自对应的第四广播。第四广播可以是
ACTION_APP_REMOTE_CARD_UPDATE,该广播的发送方为第三方APP/非第三方APP,终端车载
APP是接收方。广播中携带了第三方APP/非第三方APP需要更新待显示桌面上对应的显示内
容。其中,若采用卡片形式显示,则该第四广播包含有卡片对应的cardID以及卡片更新后需
要显示数据信息。当然,若采用表格或图标等其它形式显示,则可以无需cardID,例如当采
用图标形式还可以包括图标ID等其它任意可能需要的信息。当终端车载APP中的
RemoteCardReceiver接收至少一个第四广播后,告知终端车载 systemUI进行更新远程卡
片(update remote card)(S411)。
[0065] 在一个例子中,对于更新时发送的第四广播,若采用卡片的形式显示,则更新卡片 intent内容所采用的卡片格式与表1所示的卡片格式相同,为方便描述,在此不再赘述。
[0066] 在一个例子中,对于添加以及更新卡片,本申请的第三方APP或非第三方APP通过 RemoteView将待定意图(pending intent)、卡片view等信息发送至终端车载APP,以便终端
车载APP将相应的信息绘制到launcher上,然后在车载屏上进行显示。
[0067] 其中,RemoteView为Android的原生机制,在本申请中用于封装APP当前的状态,并通过广播机制对APP的状态进行刷新。例如正在播放的音乐、正在进行的导航、正在进行的
通话信息等等。用户通过在车载屏上显示的卡片列表,可以十分便捷的浏览到各个应用的
信息。例如图6示出的一种车载屏卡片显示示意图。此外,在RemoteView中封装了 
PendingIntent信息,PendingIntent信息中包含了接续时必要的数据,当用户点击车载屏
上对应的卡片时,可以通过PendingIntent中封装的信息,并实现无缝接续,例如接续导航、
接续音乐或接续会议等等使用场景。可以理解的是,对于更新第三方APP或非第三方APP 的
信息,可以在用户点击车载屏上相应的卡片后,针对被点击的卡片进行数据更新。当然,在
一些例子,若在车载屏上某一个APP正在被使用时,对于其它处于后台的APP,也可以周期
性、或非周期性的更新数据。
[0068] PendingIntent同样是Android的原生机制,在本申请中主要用于保存第三方APP或非第三方APP的信息,并完成对应的应用接续。在当前的Android框架下,当应用进程在车
载屏上进行显示的时候,需要将终端设备这边的第三方APP或非第三方APP的进程杀死,同
时通过PendingIntent作为应用状态信息的载体,供第三方APP或非第三方APP应用进程通
过终端车载APP启动时接续使用,即车载APP启动被杀死进程的第三方APP或非第三方APP,
将PendingIntent的信息加载到第三方APP或非第三方APP中,例如第三方APP或非第三方
APP是导航应用,PendingIntent的信息是导航应用的起点、终点、当前位置和方向等信息,
当导航应用重启时,加载PendingIntent的信息,可以使得车载屏上不中断的显示导航应用
的内容。当然,若未采用Android框架,可以无需将进程杀死,可以根据所采用的系统的相应
规范对车载屏上加载的第三方APP或非第三方APP的相应信息进行控制。
[0069] 在一个例子中,当终端车载APP将待显示的桌面绘制完成之后,通过有线或无线的方式,将绘制完成的信息传递至车载设备。使得车载设备接收终端设备传递过来的信息,并
渲染接收到的信息,以便在车载设备的车载屏上进行显示。
[0070] 本申请通过上述方式可以将不同的应用从终端设备上接续至车载设备的车载屏上进行显示,例如图7示出的一种应用接续效果示意图。可以看出图7最左侧为终端设备上
显示的地图导航应用界面,根据箭头指向图7中间部分示出了车载屏上的多卡片界面,用户
可以通过该界面浏览多个应用的卡片,当用户点击导航地图所对应的卡片时,根据箭头指
示,如图7最右侧示出的,则在车载屏上显示该卡片对应的更为详细的内容,并继续了终端
设备在接续前的导航。可以使得用户在使用上无缝衔接,极大的提升了使用的便捷性,提升
了用户体验。
[0071] 同样例如图8示出了另一种应用接续效果示意图。如图8左侧示出了在终端设备上进行前台有音乐播放器在播放音乐,后台运行了导航应用和社交应用,当终端设备与车载
设备相连接后,如图8中间部分示出的车载屏上的多卡片界面,多个卡片分别对应音乐播放
器,导航应用,社交应用(图8中未完成示出),当用户点击了表示音乐播放的卡片时,则如图
8最右侧示出的,在车载屏上显示该卡片对应的更为详细的内容,并继续播放在接续前终端
设备播放的音乐,达到无缝衔接的效果。使得用户听的音乐可以继续在车载设备上继续控
制其播放。
[0072] 可以理解的是,对于图7和图8所示出的效果,在一些实施例中,当终端设备与车载设备进行有线或无线连接后,终端设备可以对车载设备进行认证,当车载设备认证通过后,
终端设备才将待显示界面发送至车载设备的显示屏上进行显示。
[0073] 在一些例子中,对于终端设备绘制的待显示界面,若第三方APP或非第三方APP自带不同规格的显示资源,则终端设备可以参考相应APP的显示资源绘制该应用对应的卡片。
例如,第三方APP或非第三方APP携带有横屏显示资源,则当终端设备与车载设备连接后,可
以根据第三方APP或非第三方APP携带的横屏显示资源,在待显示的界面上以横屏的方式绘
制应用对应的卡片。当然若第三方APP或非第三方APP携带有针对车载屏的定制显示资源,
则可以根据第三方APP或非第三方APP携带的定制显示资源,以车载屏的显示资源绘制卡
片。显示资源中包括界面背景、图标、空间、界面布局等一个或多个显示元素。
[0074] 本申请使用卡片展示的方式进行应用接续,可以更直观、更高效地便于用户进行操作。
[0075] 继续回到图4,当第三方APP或非第三方APP在终端设备上被用户关闭时,可以通过发送第五广播至终端车载APP,终端车载APP中的RemoteCardReceiver接收第五广播 
(S412)。可以理解的是,该第五广播与第二广播、第四广播类似,可以是一个或多个,具体取
决于有多少个不同的第三方APP或非第三方APP需要移除在车载屏上自身APP对应的信息,
并发送各自第三方APP或非第三方APP对应的第五广播。例如,第五广播可以是ACTION_APP_
REMOTE_CARD_REMOVE,该广播的发送方为第三方APP或非第三方APP,作为接收方可以是终
端车载APP,其表示了第三方APP或非第三方APP想要主动移除在车载屏上显示的自身所对
应的信息,因此第三方APP或非第三方APP将第五广播发送至终端车载APP。以便移除远程信
息(S413)。其中,当APP对应的信息在车载屏上的显示的形式为卡片形式时,该第五广播包
含有需要移出的卡片所对应的cardID。当然,若采用表格或图标等其它形式显示,则可以无
需cardID,例如当采用图标形式还可以包括图标ID等其它任意可能需要的信息。可以理解
地该第五广播包含有移除卡片对应的应用的包名。
[0076] 当然可以理解的是,如果用户在车载屏上将某个APP所对应的信息删除时,也可以将该APP的信息进行移除。此时,则车载设备直接将卡片进行删除即可。或者车载设备将用
户在车载屏上的操作发送给终端设备的对应的APP,如前述方案,该APP发送第五广播给终
端车载APP,实现对应的卡片的移除。当然,在又一个例子中,若终端设备与车载设备之间有
线或无线链接中断时,终端车载APP可以移除所有卡片。在一个例子中,可以如图4示出的,
当终端设备与车载设备之间的有线链接或无线链接中断,例如无线中断或是拔掉连接线
后,终端设备将移除显示(removeDisplay())的指令发送到至framework层 (S414)。当
framework层接收removeDisplay()后,指示终端车载systemUI关闭服务 (unbindService
())(S415)。终端车载systemUI接收到unbindService()之后,通知 BroadcastSender结束
(onEnd())(S416),当BroadcastSender接收到onEnd()后可以发送第六广播(S417)和/或
第七广播(S418)至第三方APP或非第三方APP。
[0077] 在一个例子中,第六广播可以是ACTION_APP_REMOTE_CARD_REMOVED,该广播的发送方为终端车载APP,该广播中可以携带有用于指示第三方APP或非第三方APP 的指示信
息,作为接收方可以是第三方APP或非第三方APP。应当注意的是,此时第六广播的接收方为
单个应用对应的第三方APP或非第三方APP,与第三广播类似,并不是如第一广播那样进行
群发。其中,第六广播用于通知第三方APP或非第三方APP,其在车载屏上显示的对应的信息
已经被移除。若采用卡片形式显示,则该第六广播可以包含移除的卡片所对应的cardID。当
然,若采用表格或图标等其它形式显示,则可以无需cardID,例如当采用图标形式还可以包
括图标ID等其它任意可能需要的信息。
[0078] 在另一个例子中,第七广播可以是ACTION_CAR_END,该广播的发送方为终端车载APP,应当注意的是,该第七广播与第一广播类似为群发广播。其中,第七广播用于终端车载
APP通知所有第三方APP或非第三方APP此时车载设备已经与终端设备断开了连接。值得注
意的是,该第七广播并无额外数据,可以单纯作为消息广播。
[0079] 在又一个例子中,若显示的形式为卡片形式,则第五广播或第六广播中可以携带有移除的卡片信息。该卡片信息的信息格式可以如表2所示,
[0080] 表2
[0081] 关键字(key) 类型 描述cardID IntExtra 卡片唯一标识
packageName StringExtra 第三方APP包名
[0082] 上述表2示出的卡片信息格式提供了一种较为具体的移除卡片的广播intent内容。该广播格式可以包括cardID,其数据类型为整型IntExtra,用于表示卡片的唯一标识; 
packagName表示第三方APP/非第三方APP的包名,其数据类型为字符串StringExtra,可以
指示具体移除的第三方APP/非第三方APP,例如音乐、通话、地图等名称。当然可以理解的
是,若显示的形式为文本形式或图标形式等其他形式,则可以无需cardID。对于图标信息则
可以包含图标ID等任意可能需要的相关信息。
[0083] 本申请提供了一种应用显示接续方法,通过该方法可以对任意有需求的第三方APP 或非第三方APP进行接续。若采用原有的界面显示资源,则接续的应用在车载屏上打开
后仍然符合终端设备上的横屏布局或PAD布局,其继承了原有的终端设备界面的原始形态,
不用改变用户的使用习惯,符合用户使用的连续性。当然也可以采用适配车载屏的界面显
示资源,以便更加适配车载屏上的显示。同时,可以做到任意种类、任意数量的应用同时进
行接续,保证了用户使用车载设备时多业务的连续性,大大提升了在车载设备上操作不同
应用的便捷性。
[0084] 本领域技术人员应当注意的是,本申请可以支持所有可以实现接口的第三方应用进行接续。本申请同样可以适用于多屏框架的其它形态,例如终端设备将屏幕接续至电视、
投影仪、PAD等,从而实现多应用的跨屏幕接续。
[0085] 图9为本申请实施例提供的一种应用显示接续方法流程图。
[0086] 如图9所示,本申请公开了一种应用显示接续方法,该方法应用在终端设备上,终端设备与车载设备通过有线或无线相连接,终端设备上运行着第一应用和至少一个第二应
用。其中第一应用可以管理投屏的APP,例如上述的终端车载APP;第二应用可以是上述接续
APP,该方法可以包括以下步骤:
[0087] S901,第一应用发送第一广播到至少一个第二应用。
[0088] 当第一应用发送第一广播到至少一个第二应用后,第二应用根据第一广播发送第二广播至第一应用。至少一个第二应用可以包括两个应用,比如导航应用和音乐播放应用。
[0089] S902,第一应用接收至少一个第二应用发送的第二广播,其中,第二广播包括第二应用的第一数据信息。
[0090] 在一个可能的实施方式中,第一数据信息可以包括:第二应用所对应卡片的卡片标识、第二应用的包名、第二应用所对应卡片的卡片类型、第二应用所对应的卡片的优先级
和第二应用的内容中的一个或多个。当然,本领域技术人员应当注意,还可以根据实际需求
增加任意信息。例如导航应用和音乐播放应用分别发送第二广播。
[0091] S903,第一应用根据第一数据信息,生成第二应用所对应的卡片,绘制待在车载设备上显示的界面。终端设备将待显示界面发送至车载设备上进行展示。
[0092] S904,当用户在车载设备的车载屏上点击第二应用所对应的卡片时,车载设备通知第一应用,使得第一应用结合第二应用的第一数据信息,将第二应用的内容在车载设备
上进行详细展示。
[0093] S905,第一应用发送至少一个第三广播到至少一个第二应用,以告知至少一个第二应用卡片添加成功。第二应用接收第一应用发送的第三广播。
[0094] 图10为本申请实施例提供的另一种应用显示接续方法流程图。
[0095] 如图10所示,本申请公开了另一种应用显示接续方法,当第二应用需要主动更新其对应卡片的卡片内容时,在S905之后,该方法还可以包括以下步骤:
[0096] S1001,第一应用接收至少一个第二应用发送的至少一个第四广播,其中,第四广播包括第二应用的第二数据信息。
[0097] 在一个可能的实施方式中,第二数据信息可以包括:第二应用所对应卡片的卡片标识、第二应用的包名、第二应用所对应卡片的卡片类型、第二应用所对应的卡片的优先级
和第二应用的内容中的一个或多个。当然,本领域技术人员应当注意,还可以根据实际需求
增加任意信息。第二数据信息类似第一数据信息。
[0098] S1002,根据第二应用的第二数据信息,第一应用更新在车载设备上展示的第二应用的内容。
[0099] 可以理解的是,图10所示出的更新过程,可以是当用户点击某个APP后,详细展示该APP的信息时,针对该APP单独更新;当然对于处于后台运行的其它APP在一些例子中,也
可以更新。
[0100] 图11为本申请实施例提供的又一种应用显示接续方法流程图。
[0101] 如图11所示,本申请公开了又一种应用显示接续方法,当第二应用需要主动移除其对应的卡片时,在S905或S1002之后,该方法还可以包括以下步骤:
[0102] S1101,第一应用接收至少一个第二应用发送的至少一个第五广播,其中,第五广播包括第二应用的第三数据信息。
[0103] 在一个可能的实施方式中,第三数据信息可以包括:第二应用所对应卡片的卡片标识和第二应用的包名中的一个或多个。当然,本领域技术人员应当注意,还可以根据实际
需求增加任意信息。
[0104] S1102,根据第五广播,移除在车载设备上显示的第二应用所对应的卡片。
[0105] 在一个可能的实施方式中,根据第五广播以及第五广播中包括的第二应用的第三数据信息,第一应用移除在车载设备上显示的第二应用所对应的卡片。
[0106] 图12为本申请实施例提供的再一种应用显示接续方法流程图。
[0107] 如图12所示,本申请公开了再一种应用显示接续方法,在S905、S1002或S1102之后,终端设备与车载设备可能会断开连接,而在终端设备与车载设备断开连接后,在车载屏
上显示的第二应用所对应的信息将被终端车载APP全部移除,该方法还可以包括以下步骤:
[0108] S1201,当终端设备与车载设备断开连接时,第一应用发送至少一个第六广播到至少一个第二应用,以告知至少一个第二应用所对应的卡片被移除。可以理解的是,第六广播
携带有卡片的ID。
[0109] S1202,发送第七广播到至少一个第二应用,以告知至少一个第二应用终端设备与车载设备之间的有线连接或无线连接已经断开。第七广播可以是群发广播,类似第一广播。
[0110] 当然可以理解的是S1201与S1202之间没有必然的先后顺序,也可以先执行S1202 后执行S1201,再或者只执行S1201或只执行S1202。
[0111] 图13为本申请实施例提供的一种终端设备示意图。
[0112] 如图13所示,提供了一种终端设备1300,可以包括处理器1310,外部存储器接口 1320,内部存储器1321,通用串行总线(universal serial bus,USB)接口1330,充电管理模
块1340,电源管理模块1341,电池1342,天线1,天线2,移动通信模块1350,无线通信模块
1360,音频模块1370,扬声器1370A,受话器1370B,麦克风1370C,耳机接口 1370D,传感器模
块1380,按键1390,马达1391,指示器1392,摄像头1393,显示屏1394,以及用户标识模块
(subscriber identification module,SIM)卡接口1395等。其中传感器模块1380可以包括
压力传感器1380A,陀螺仪传感器1380B,气压传感器1380C,磁传感器 1380D,加速度传感器
1380E,距离传感器1380F,接近光传感器1380G,指纹传感器1380H,温度传感器1380J,触摸
传感器1380K,环境光传感器1380L,骨传导传感器1380M等。
[0113] 可以理解的是,本发明实施例示意的结构并不构成对电子设备1300的具体限定。在本申请另一些实施例中,电子设备1300可以包括比图示更多或更少的部件,或者组合某
些部件,或者拆分某些部件,或者不同的部件布置。图示的部件可以以硬件,软件或软件和
硬件的组合实现。
[0114] 处理器1310可以包括一个或多个处理单元,例如:处理器1310可以包括应用处理器(application processor,AP),中央处理器(central processing unit,CPU),调制解调
处理器,图形处理器(graphics processing unit,GPU),图像信号处理器(image signal 
processor, ISP),控制器,视频编解码器,数字信号处理器(digital signal processor,
DSP),基带处理器,和/或神经网络处理器(neural‑networkprocessing unit,NPU)等。其
中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。
[0115] 处理器1310可以根据指令操作码和时序信号,产生操作控制信号,完成取指令和执行指令的控制。
[0116] 处理器1310中还可以设置存储器,用于存储指令和数据。在一些实施例中,处理器 110中的存储器为高速缓冲存储器。该存储器可以保存处理器1310刚用过或循环使用的指
令或数据。如果处理器1310需要再次使用该指令或数据,可从所述存储器中直接调用。避免
了重复存取,减少了处理器1310的等待时间,因而提高了系统的效率。
[0117] 在一些实施例中,处理器1310可以包括一个或多个接口。接口可以包括集成电路 (inter‑integrated circuit,I2C)接口,集成电路内置音频(inter‑integrated circuit 
sound,I2S) 接口,脉冲编码调制(pulse code modulation,PCM)接口,通用异步收发传输
器(universal asynchronous receiver/transmitter,UART)接口,移动产业处理器接口
(mobile industry processor interface,MIPI),通用输入输出(general‑purpose 
input/output,GPIO)接口,用户标识模块(subscriber identity module,SIM)接口和/或
通用串行总线(universal serial bus, USB)接口等。
[0118] 可以理解的是,本发明实施例示意的各模块间的接口连接关系,只是示意性说明,并不构成对电子设备1300的结构限定。在本申请另一些实施例中,电子设备1300也可以采
用上述实施例中不同的接口连接方式,或多种接口连接方式的组合。
[0119] 充电管理模块1340用于从充电器接收充电输入。其中,充电器可以是无线充电器,也可以是有线充电器。在一些有线充电的实施例中,充电管理模块1340可以通过USB接口
1330接收有线充电器的充电输入。在一些无线充电的实施例中,充电管理模块1340可以通
过电子设备1300的无线充电线圈接收无线充电输入。充电管理模块1340为电池1342 充电
的同时,还可以通过电源管理模块1341为电子设备供电。
[0120] 电源管理模块1341用于连接电池1342,充电管理模块1340与处理器1310。电源管理模块1341接收电池1342和/或充电管理模块1340的输入,为处理器1310,内部存储器 
1321,显示屏1394,摄像头1393,和无线通信模块1360等供电。电源管理模块1341还可以用
于监测电池容量,电池循环次数,电池健康状态(漏电,阻抗)等参数。在其他一些实施例中,
电源管理模块1341也可以设置于处理器1310中。在另一些实施例中,电源管理模块1341和
充电管理模块1340也可以设置于同一个器件中。
[0121] 电子设备1300的无线通信功能可以通过天线1,天线2,移动通信模块1350,无线通信模块1360,调制解调处理器以及基带处理器等实现。
[0122] 天线1和天线2用于发射和接收电磁波信号。电子设备1300中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用,以提高天线的利用率。例如:可以将天线1
复用为无线局域网的分集天线。在另外一些实施例中,天线可以和调谐开关结合使用。
[0123] 移动通信模块1350可以提供应用在电子设备1300上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块1350可以包括至少一个滤波器,开关,功率放大器,低噪声放
大器(lownoise amplifier,LNA)等。移动通信模块1350可以由天线1接收电磁波,并对接收
的电磁波进行滤波,放大等处理,传送至调制解调处理器进行解调。移动通信模块 1350还
可以对经调制解调处理器调制后的信号放大,经天线1转为电磁波辐射出去。在一些实施例
中,移动通信模块1350的至少部分功能模块可以被设置于处理器1310中。在一些实施例中,
移动通信模块1350的至少部分功能模块可以与处理器1310的至少部分模块被设置在同一
个器件中。
[0124] 无线通信模块1360可以提供应用在电子设备1300上的包括无线局域网(wireless local area networks,WLAN),例如无线保真(wireless fidelity,Wi‑Fi)网络,蓝牙
(bluetooth, BT),全球导航卫星系统(global navigation satellite system,GNSS),调
频(frequency modulation,FM),近距离无线通信技术(near field communication,NFC),
红外技术(infrared, IR)等无线通信的解决方案。无线通信模块1360可以是集成至少一个
通信处理模块的一个或多个器件。无线通信模块1360经由天线2接收电磁波,将电磁波信号
调频以及滤波处理,将处理后的信号发送到处理器1310。无线通信模块1360还可以从处理
器1310接收待发送的信号,对其进行调频,放大,经天线2转为电磁波辐射出去。
[0125] 在一些实施例中,电子设备1300的天线1和移动通信模块1350耦合,天线2和无线通信模块1360耦合,使得电子设备1300可以通过无线通信技术与网络以及其他设备通信。
所述无线通信技术可以包括全球移动通讯系统(global  system formobile 
communications, GSM),通用分组无线服务(general packet radio service,GPRS),码分
多址接入(code division multiple access,CDMA),宽带码分多址(wideband code 
division multiple access,WCDMA),时分码分多址(time‑division code division 
multiple access,TD‑SCDMA),长期演进(long term evolution,LTE),BT,GNSS,WLAN,NFC,
FM和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system,
GPS),全球导航卫星系统(global navigation satellite system,GLONASS),北斗卫星导
航系统(beidou navigation satellite system, BDS),准天顶卫星系统(quasi‑zenith 
satellite system,QZSS)和/或星基增强系统(satellite based augmentation systems,
SBAS)。
[0126] 显示屏1394用于显示图像,视频等。显示屏1394包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display,LCD),有机发光二极管(organic light‑emitting 
diode, OLED),有源矩阵有机发光二极体或主动矩阵有机发光二极体(active‑matrix 
organic light emitting diode,AMOLED),柔性发光二极管(flex light‑emitting 
diode,FLED),Miniled, MicroLed,Micro‑oLed,量子点发光二极管(quantum dot light 
emitting diodes,QLED)等。在一些实施例中,电子设备1300可以包括1个或N个显示屏
1394,N为大于1的正整数。
[0127] 电子设备1300可以通过ISP,摄像头1393,视频编解码器,GPU,显示屏1394以及应用处理器等实现拍摄功能。
[0128] 摄像头1393用于捕获静态图像或视频。
[0129] 外部存储器接口1320可以用于连接外部存储卡,例如Micro SD卡,实现扩展电子设备1300的存储能力。外部存储卡通过外部存储器接口1320与处理器1310通信,实现数据
存储功能。例如将音乐,视频等文件保存在外部存储卡中。
[0130] 内部存储器1321可以用于存储计算机可执行程序代码,所述可执行程序代码包括指令。内部存储器1321可以包括存储程序区和存储数据区。其中,存储程序区可存储操作系
统,至少一个功能所需的应用程序(比如声音播放功能,图像播放功能等)等。存储数据区可
存储电子设备1300使用过程中所创建的数据(比如音频数据,电话本等)等。此外,内部存储
器1321可以包括易失性存储器(volatile memory),例如高速随机存取存储器 (random‑
access memory,RAM);还可以包括非易失性存储器(non‑volatile memory),例如至少一个
磁盘存储器件,通用闪存存储器(universal flash storage,UFS),只读存储器(read‑only 
memory,ROM),快闪存储器,硬盘(hard disk drive,HDD)或固态硬盘 (solid state 
drive,SSD等,存储器1602还可以包括上述种类的存储器的组合。处理器1310 通过运行存
储在内部存储器1321的指令和/或存储在设置于处理器中的存储器的指令,执行电子设备
1300的各种功能应用以及数据处理。
[0131] 电子设备1300可以通过音频模块1370,扬声器1370A,受话器1370B,麦克风1370C,耳机接口1370D,以及应用处理器等实现音频功能。例如音乐播放,录音等。
[0132] 音频模块1370用于将数字音频信息转换成模拟音频信号输出,也用于将模拟音频输入转换为数字音频信号。音频模块1370还可以用于对音频信号编码和解码。在一些实施
例中,音频模块1370可以设置于处理器1310中,或将音频模块1370的部分功能模块设置于
处理器1310中。
[0133] 电子设备100的软件系统可以采用分层架构,事件驱动架构,微核架构,微服务架构,或云架构。本发明实施例以分层架构的Android系统为例,示例性说明电子设备1300 的
软件结构。
[0134] 当处理器1310与内部存储器1321耦合,读取并执行内部存储器1321中的指令;当处理器1310运行时执行指令,使得处理器1310还用于执行上述图2至图12 所示的方法。
[0135] 本领域普通技术人员应该还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清
楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组
成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计
约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但
是这种实现不应认为超出本申请的范围。
[0136] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令处理器完成,所述的程序可以存储于计算机可读存储介质中,所述存储介
质是非短暂性(英文:non‑transitory)介质,例如随机存取存储器,只读存储器,快闪存储
器,硬盘,固态硬盘,磁带(英文:magnetic tape),软盘(英文:floppy disk),光盘(英文: 
optical disc)及其任意组合。
[0137] 以上所述,仅为本申请较佳的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到的变化或替换,
都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应该以权利要求的保护范围
为准。