CN115145474A

CN115145474A - 一种功能迁移方法和装置

Info

Publication number: CN115145474A
Application number: CN202110352451.1A
Authority: CN
Inventors: 邓辉平; 陈冬郎; 鲍思源; 程高超
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-03-31
Filing date: 2021-03-31
Publication date: 2022-10-04
Also published as: WO2022206676A1

Abstract

本申请实施例提供一种功能迁移方法和装置，涉及终端领域，能够保证数据分享的安全可靠。其方法为：第一设备向第二设备发送第一请求，第一请求携带第一设备的标识、第一应用的标识和第二应用的标识；从第二设备接收第一响应，第一响应用于指示第二设备创建的第一群组，第一群组的成员包括第二设备的第二应用；向第二设备发送第二请求，第二请求用于申请将第一设备的第一应用加入第一群组；将第一应用中的第一功能迁移到第二设备的第二应用，第一功能包括一个或者多个图形用户界面。

Description

一种功能迁移方法和装置

技术领域

本申请涉及终端领域，尤其涉及一种功能迁移方法和装置。

背景技术

随着智能手机、平板、个人计算机(personal computer，PC)等数字化设备的普及和发展，个人终端数量激增，不同设备之间具有分享业务数据的需求。因此，如何分享业务数据以保证数据的安全可靠成为一个亟待解决的问题。

发明内容

本申请实施例提供一种功能迁移方法和装置，能够保证数据分享的安全可靠。

第一方面，本申请实施例提供一种功能迁移方法，应用于第一设备，方法包括：向第二设备发送第一请求，第一请求携带第一设备的标识、第一应用的标识和第二应用的标识；从第二设备接收第一响应，第一响应用于指示第二设备创建的第一群组，第一群组的成员包括第二设备的第二应用；向第二设备发送第二请求，第二请求用于申请将第一设备的第一应用加入第一群组；将第一应用中的第一功能迁移到第二设备的第二应用，第一功能包括一个或者多个图形用户界面(user interface，UI)。

基于本申请实施例提供的方法，经过第一设备和第二设备的协商，第一设备的第一应用和第二设备的第二应用可以加入第一群组，即第一群组的成员可以包括第一设备的第一应用和第二设备的第二应用。由于第一群组是经过第一设备和第二设备协商后建立的，因此在第一群组的成员之间迁移功能数据，例如迁移第一功能的一个或者多个UI，能够保证数据分享的安全可靠。

在一种可能的实现方式中，第一响应包括第一群组对应的个人识别密码(personal identification number，PIN)和/或第二设备的通信连接信息；向第二设备发送第二请求，包括：根据PIN和/或第二设备的通信连接信息向第二设备发送第二请求。这样，当第一设备需要加入第二设备创建的群组时，可以在请求中携带群组对应的PIN，以便第二设备可以根据PIN对第一设备的安全性进行校验，从而可以保证数据分享的安全可靠。

在一种可能的实现方式中，方法还包括：接收第二响应，其中，第二响应用于指示第一设备的第一应用已加入第一群组。这样，第一设备可以获知第一应用已加入第一群组，以便后续可以直接进行功能迁移。

在一种可能的实现方式中，方法还包括：创建第二群组，其中，第二群组的成员包括第一设备的第一应用以及第二设备的第二应用。也就是说，第一设备可以在本地创建一个群组(即第二群组)，该群组与第二设备创建的群组相同。这样，当第二设备的第二应用向第一设备的第一应用进行功能迁移时，若第一设备确定本地保存有第二群组，可以认为第二设备的第二应用是安全可信的，可以直接进行功能迁移。

在一种可能的实现方式中，方法还包括：响应于用户在第一设备的第一应用的第一操作，显示第一弹框，第一弹框包括与第一设备处于同一个网络中的设备的标识；向第二设备发送第一请求，包括：响应于用户在第一弹框中选中第二设备的第二操作，向第二设备发送第一请求。这样，可以通过第一弹框供用户选择需要进行功能迁移的设备。

在一种可能的实现方式中，与第一设备处于同一个网络中的设备包括可信设备和不可信设备；其中，可信设备包括与第一设备登录同一个账号的设备、与第一设备进行过设备级认证的设备或者与第一设备的第一应用进行过应用级认证的设备；不可信设备包括未与第一设备登录同一个账号的设备、未与第一设备进行过设备级认证的设备或者未与第一设备的第一应用进行过应用级认证的设备。这样，可以向用户提示可信设备和不可信设备，方便用户管理相应的设备。

在一种可能的实现方式中，方法还包括：扫描第二设备显示的二维码图片，二维码图片包括第一群组对应的个人识别码PIN和/或第二设备的通信连接信息，向第二设备发送第二请求，包括：根据PIN和/或第二设备的通信连接信息向第二设备发送第二请求。这里以二维码图片为标识符进行示意说明，可以将二维码图片替换为其他类型的标识符，例如条形码、字符串等，本申请不做限定。

在一种可能的实现方式中，将第一应用中的第一功能迁移到第二设备包括：向第二设备发送第一功能的业务信息；当第一应用为直播应用时，第一功能的业务信息包括第一设备的直播间的视频流、音频流以及弹幕信息中的至少一种；或者当第一应用为拍照应用时，第一功能的业务信息包括拍摄预览画面或拍摄界面的菜单栏信息；或者当第一应用为K歌应用时，第一功能的业务信息包括歌名、歌词、歌曲的音频信息歌曲的视频信息、歌曲的控制界面中的至少一种；或者当第一应用为购物应用时，第一功能的业务信息包括购物车中的商品信息；或者当第一应用为邮件应用时，第一功能的业务信息包括邮件的主题、正文和附件中的至少一种。

这样，在不同的场景下，可以将第一设备上不同的应用程序(例如，直播应用、拍照应用、K歌应用、邮件应用或购物应用)的部分功能迁移到第二设备上，可以满足跨设备迁移功能的需求。

在一种可能的实现方式中，所述第二设备的通信连接信息包括所述第二设备的无线保真Wi-Fi地址或蓝牙地址。

在一种可能的实现方式中，所述方法还包括：向第三设备发送第三请求，所述第三请求携带所述第一设备的标识、第一应用的包名和第三应用的包名；所述第三请求用于请求将所述第一应用的第一功能迁移到所述第三设备的所述第三应用；接收第二响应，所述第二响应包括同意迁移的信息和所述第三设备创建的第二群组的群组名，所述第二群组的成员包括所述第一设备的所述第一应用以及所述第三设备的所述第三应用；向所述第三设备发送第四请求，所述第四请求用于申请加入所述第二群组，所述第四请求包括所述第二群组的群组名；将所述第一应用中的所述第一功能迁移至所述第三设备。

在一种可能的实现方式中，所述方法还包括更新本地保存的所述第一群组的成员，更新后的所述第一群组的成员包括所述第一设备的所述第一应用、所述第二设备的所述第二应用和所述第三设备的所述第三应用。

在一种可能的实现方式中，所述第二应用的包名和所述第一应用的包名相同。

在一种可能的实现方式中，所述可信设备包括第三设备，响应于用户从所述可信设备中删除所述第三设备的操作，删除与所述第三设备相关的群组。

在一种可能的实现方式中，所述第一群组被设置为永久有效或在预设时间内有效。

在一种可能的实现方式中，当第一应用为K歌应用时，所述方法还包括：重新编排点歌控制UI；响应于用户在所述点歌控制UI进行点歌、切歌的操作，将点歌、切歌信息发送给所述第二设备。

在一种可能的实现方式中，当所述第一应用为购物应用时，所述第一功能的业务信息包括购物车中的商品信息，所述商品信息包括商品名、商品链接和商品价格信息中的至少一种。

在一种可能的实现方式中，当所述第一应用为邮件应用时，所述第一功能的业务信息包括邮件的主题、正文或附件中的至少一种。

第二方面，本申请实施例提供一种功能迁移方法，应用于第二设备，方法包括：接收来自第一设备的第一请求，第一请求携带第一设备的标识、第一应用的标识和第二应用的标识；创建第一群组，第一群组的成员包括第二设备的第二应用；向第一设备发送第一响应，第一响应用于指示第一群组；接收来自第一设备的第二请求，第二请求用于申请将第一设备的第一应用加入第一群组。接收第一设备迁移的第一应用中的第一功能，其中，第一功能包括一个或者多个图形用户界面UI。

在一种可能的实现方式中，第一响应包括第一群组对应的个人识别码PIN和/或第二设备的通信连接信息。这样，第二设备可以根据PIN对第一设备的安全性进行校验，从而可以保证数据分享的安全可靠。

在一种可能的实现方式中，方法还包括：向第一设备发送第二响应，其中，第二响应用于指示第一设备的第一应用已加入第二群组。这样，第一设备可以获知第一应用已加入第一群组，以便后续可以直接进行功能迁移。

在一种可能的实现方式中，从第一设备接收第一请求之后，方法还包括：显示第一弹框，第一弹框用于提示用户是否同意将第一设备的第一应用加入第一群组；接收来自用户的同意指令。这样，可以通过第一弹框提示用户将第一设备的第一应用加入第一群组。

在一种可能的实现方式中，在创建第一群组之前，方法还包括：根据第一设备的标识确定第二设备当前没有第二群组，其中，第二群组的成员包括第一设备和第二设备。即确定第一设备和第二设备之间没有建立群组的情况下，也就是第一设备和第二设备在先没有建立过程可信连接的情况下，可以创建第一群组。

在一种可能的实现方式中，在创建第一群组之前，方法还包括：根据第一设备的标识、第一应用的标识和第二应用的标识，确定第二设备当前没有第三群组，其中，第三群组的成员包括第一设备的第一应用以及第二设备的第二应用。即确定第一设备的第一应用以及第二设备的第二应用之间没有建立群组的情况下，也就是第一设备的第一应用以及第二设备的第二应用在先没有建立过程可信连接的情况下，可以创建第一群组。

在一种可能的实现方式中，方法还包括：显示二维码图片，二维码图片包括第一群组对应的个人识别码PIN和/或第二设备的通信连接信息。这里以二维码图片为标识符进行示意说明，可以将二维码图片替换为其他类型的标识符，例如条形码、字符串等，本申请不做限定。

在一种可能的实现方式中，接收第一设备迁移的第一应用中的第一功能包括：接收来自第一设备的第一功能的业务信息；当第一应用为直播应用时，第一功能的业务信息包括第一设备的直播间的视频流、音频流以及弹幕信息中的至少一种；或者当第一应用为拍照应用时，第一功能的业务信息包括拍摄预览画面或拍摄界面的菜单栏信息；或者当第一应用为K歌应用时，第一功能的业务信息包括歌名、歌词、歌曲的音频信息歌曲的视频信息、歌曲的控制界面中的至少一种；或者当第一应用为购物应用时，第一功能的业务信息包括购物车中的商品信息；或者当第一应用为邮件应用时，第一功能的业务信息包括邮件的主题、正文和附件中的至少一种。

在一种可能的实现方式中，第二设备的通信连接信息包括第二设备的无线保真Wi-Fi地址或蓝牙地址。

在一种可能的实现方式中，第二应用的包名和第一应用的包名相同。

在一种可能的实现方式中，第一群组被设置为永久有效或在预设时间内有效。

在一种可能的实现方式中，从第一设备接收第一请求之后，方法还包括：显示第二弹框，第二弹框用于提示用户是否同意第一设备将第一功能迁移至第二设备。

在一种可能的实现方式中，若第二设备安装直播应用，第二设备检测直播应用是否登录；若直播应用为登录状态，直播应用在第二设备的直播画面上展示第一功能。

在一种可能的实现方式中，若第二设备未安装直播应用，第二设备以音频播放器的形式展示第一功能。

在一种可能的实现方式中，当第一应用为拍照应用时，第一功能的业务信息包括拍摄预览画面和拍摄界面的菜单栏信息。

在一种可能的实现方式中，第二设备显示第一设备的拍摄预览画面和拍摄界面的菜单栏；响应于用户在第二设备触发第一设备进行拍摄的操作，向第一设备发送拍摄指令，第一设备拍摄照片或视频。

在一种可能的实现方式中，当第一应用为K歌应用时，若第二设备安装K歌应用，检测K歌应用是否登录；若K歌应用为登录状态，K歌应用展示第一功能。

在一种可能的实现方式中，当第一应用为K歌应用时，若第二设备未安装K歌应用，以音频播放器的形式展示第一功能。

在一种可能的实现方式中，当第一应用为购物应用时，若第二设备安装购物应用，检测购物应用是否登录；若购物应用为登录状态，购物应用根据第一功能的业务信息显示共享购物车，共享购物车包括第二设备的购物车中的全部商品和第一设备的购物车中的全部商品。

在一种可能的实现方式中，响应于用户结算共享购物车中全部商品的操作，第二设备向第一设备发送付款请求，付款请求包括第一设备的购物车中的全部商品的总金额。

在一种可能的实现方式中，当第一应用为邮件应用时，若第二设备安装邮箱应用，检测邮箱应用是否登录；若邮箱应用为登录状态，邮箱应用展示第一功能。

在一种可能的实现方式中，当第一应用为邮件应用时，若第二设备未安装邮箱应用，以图文编辑器的形式对第一功能进行编码重排显示。

第三方面，本申请实施例提供一种功能迁移方法，应用于包括第一设备和第二设备的通信系统，方法包括：第一设备向第二设备发送第一请求，第一请求携带第一设备的标识；第二设备从第一设备接收第一请求；第二设备从第一设备发送第一响应，第一响应用于指示第二设备创建的第一群组，第一群组的成员包括第二设备；第一设备从第二设备接收第一响应；第一设备向第二设备发送第二请求，第二请求用于申请将第一设备加入第一群组；第一设备将第一应用中的第一功能迁移至第二设备，第一应用为第一设备中的任一个应用，第一功能包括一个或多个图形用户界面UI。

在一种可能的实现方式中，第一响应包括第一群组对应的个人识别码PIN和/或第二设备的通信连接信息，向第二设备发送第二请求，包括：根据PIN和/或第二设备的通信连接信息向第二设备发送第二请求；方法还包括：从第二设备接收第二响应，第二响应用于指示第一设备已加入第一群组。

在一种可能的实现方式中，响应于用户的第一操作，第一设备显示第一弹框，第一弹框包括一个或多个未与第一设备进行过认证的设备的标识；第一设备向第二设备发送第一请求，包括：响应于用户在第一弹框中选择第二设备的第二操作，向第二设备发送第一请求。

在一种可能的实现方式中，方法还包括：第一设备创建第二群组，第二群组的成员包括第一设备以及第二设备。

在一种可能的实现方式中，方法还包括：响应于用户在第一设备的第一应用的第一操作，第一设备显示第一弹框，第一弹框包括与第一设备处于同一个网络中的设备的标识；第一设备向第二设备发送第一请求，包括：第一设备响应于用户在第一弹框中选中第二设备的第二操作，向第二设备发送第一请求。

在一种可能的实现方式中，与第一设备处于同一个网络中的设备包括可信设备和不可信设备；其中，可信设备包括与第一设备登录同一个账号的设备、与第一设备进行过设备级认证的设备或者与第一设备的第一应用进行过应用级认证的设备；不可信设备包括未与第一设备登录同一个账号的设备、未与第一设备进行过设备级认证的设备或者未与第一设备的第一应用进行过应用级认证的设备。

在一种可能的实现方式中，方法还包括：第二设备显示二维码图片，二维码图片包括第一群组对应的个人识别码PIN和/或第二设备的通信连接信息；第一设备扫描第二设备显示的二维码图片；第一设备向第二设备发送第二请求，包括：第一设备根据PIN和/或第二设备的通信连接信息向第二设备发送第二请求。

在一种可能的实现方式中，第一设备将第一应用中的第一功能迁移至第二设备包括：向第二设备发送第一功能的业务信息；当第一应用为直播应用时，第一功能的业务信息包括第一设备的直播间的视频流、音频流以及弹幕信息中的至少一种；或者当第一应用为拍照应用时，第一功能的业务信息包括拍摄预览画面或拍摄界面的菜单栏信息；或者当第一应用为K歌应用时，第一功能的业务信息包括歌名、歌词、歌曲的音频信息歌曲的视频信息、歌曲的控制界面中的至少一种；或者当第一应用为购物应用时，第一功能的业务信息包括购物车中的商品信息；或者当第一应用为邮件应用时，第一功能的业务信息包括邮件的主题、正文和附件中的至少一种。

第四方面，本申请实施例提供一种功能迁移方法，应用于第一设备，包括：创建第一群组，第一群组的成员包括第一设备的第一应用；从第二设备接收第一请求，第一请求用于申请将第二设备的第二应用加入第一群组；将第二设备的第二应用加入第一群组；将第一应用中的第一功能迁移到第二设备的第二应用，第二功能包括一个或者多个图形用户界面UI。

在一种可能的实现方式中，在从第二设备接收第一请求之前，方法还包括：显示用于指示第一群组的第一标识符，其中，第一请求与第一标识符相对应。

在一种可能的实现方式中，第一标识符包括二维码图片，第一标识符包括个人识别码PIN；从第二设备接收第一请求之后，方法还包括：确定第一请求中携带PIN；确定将第二设备的第二应用加入第一群组。

在一种可能的实现方式中，将第一应用中的第一功能迁移到第二设备的第二应用包括：向第二设备发送第一功能的业务信息；当第一应用为直播应用时，第一功能的业务信息包括第一设备的直播间的视频流、音频流以及弹幕信息中的至少一种；或者当第一应用为拍照应用时，第一功能的业务信息包括拍摄预览画面或拍摄界面的菜单栏信息；或者当第一应用为K歌应用时，第一功能的业务信息包括歌名、歌词、歌曲的音频信息歌曲的视频信息、歌曲的控制界面中的至少一种；或者当第一应用为购物应用时，第一功能的业务信息包括购物车中的商品信息；或者当第一应用为邮件应用时，第一功能的业务信息包括邮件的主题、正文和附件中的至少一种。

第五方面，本申请实施例提供一种功能迁移方法，应用于第二设备，包括：向第一设备发送第一请求，第一请求用于申请将第二设备的第二应用加入第一设备创建的第一群组，第一群组的成员包括第一设备的第一应用和第二设备的第二应用；从第一设备接收第一应用中的第一功能，其中，第一功能包括一个或者多个图形用户界面UI。

在一种可能的实现方式中，在向第一设备发送第一请求之前，方法还包括：扫描用于指示第一群组的第一标识符，其中，第一请求与第一标识符相对应。

在一种可能的实现方式中，第一标识符包括二维码图片，第一标识符包括个人识别码PIN；向第一设备发送第一请求包括：向第一设备发送第一请求，第一请求中携带PIN。

在一种可能的实现方式中，从第一设备接收第一应用中的第一功能包括：从第一设备接收第一功能的业务信息；当第一应用为直播应用时，第一功能的业务信息包括第一设备的直播间的视频流、音频流以及弹幕信息中的至少一种；或者当第一应用为拍照应用时，第一功能的业务信息包括拍摄预览画面或拍摄界面的菜单栏信息；或者当第一应用为K歌应用时，第一功能的业务信息包括歌名、歌词、歌曲的音频信息歌曲的视频信息、歌曲的控制界面中的至少一种；或者当第一应用为购物应用时，第一功能的业务信息包括购物车中的商品信息；或者当第一应用为邮件应用时，第一功能的业务信息包括邮件的主题、正文和附件中的至少一种。

第六方面，本申请提供了一种第一设备，包括一个或多个处理器和一个或多个存储器。该一个或多个存储器与一个或多个处理器耦合，一个或多个存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，使得第一设备执行上述第一方面或第三方面或第四方面中任一方面任一项可能的实现方式中的方法。

第七方面，本申请提供了一种第二设备，包括一个或多个处理器和一个或多个存储器。该一个或多个存储器与一个或多个处理器耦合，一个或多个存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，使得第二设备执行上述第二方面或第三方面或第五方面中任一方面任一项可能的实现方式中的方法。

第八方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行上述任一方面任一项可能的实现方式中的方法。

第九方面，本申请提供一种芯片系统，该芯片系统可以设置于第一设备中。该芯片系统包括一个或多个接口电路和一个或多个处理器。该接口电路和处理器通过线路互联。该芯片系统可以应用于包括通信模块和存储器的电子设备。该接口电路用于存储器接收信号，并向处理器发送接收到的信号，该信号包括存储器中存储的计算机指令。当处理器执行该计算机指令时，第一设备可以执行上述任一方面及其任一种可能的实现方式所述的方法。

第十方面，本申请实施例提供了一种计算机存储介质，包括计算机指令，当计算机指令在第一设备上运行时，使得第一设备执行上述任一方面任一项可能的实现方式中的方法。

第十一方面，本申请实施例提供一种功能迁移系统，包括至少两个设备(例如第一设备和第二设备)，每个设备可以执行上述任一方面及其任一种可能的实现方式所述的方法。

附图说明

图1为本申请实施例提供的一种系统架构示意图；

图2为本申请实施例提供的又一种系统架构示意图；

图3为本申请实施例提供的一种电子设备的硬件结构示意图；

图4为本申请实施例提供的一种电子设备的软件架构示意图；

图5A为本申请实施例提供的一种显示示意图；

图5B为本申请实施例提供的又一种显示示意图；

图5C为本申请实施例提供的又一种显示示意图；

图5D为本申请实施例提供的又一种显示示意图；

图5E为本申请实施例提供的又一种显示示意图；

图5F为本申请实施例提供的又一种显示示意图；

图6A为本申请实施例提供的又一种显示示意图；

图6B为本申请实施例提供的又一种显示示意图；

图6C为本申请实施例提供的又一种显示示意图；

图7A为本申请实施例提供的一种信号交互示意图；

图7B为本申请实施例提供的又一种信号交互示意图；

图7C为本申请实施例提供的又一种信号交互示意图；

图8A为本申请实施例提供的又一种显示示意图；

图8B为本申请实施例提供的又一种显示示意图；

图8C为本申请实施例提供的又一种显示示意图；

图8D为本申请实施例提供的又一种显示示意图；

图8E为本申请实施例提供的又一种显示示意图；

图9A为本申请实施例提供的又一种信号交互示意图；

图9B为本申请实施例提供的又一种信号交互示意图；

图9C为本申请实施例提供的又一种信号交互示意图；

图10A为本申请实施例提供的又一种显示示意图；

图10B为本申请实施例提供的又一种显示示意图；

图11为本申请实施例提供的又一种信号交互示意图；

图12A为本申请实施例提供的又一种显示示意图；

图12B为本申请实施例提供的又一种显示示意图；

图12C为本申请实施例提供的又一种显示示意图；

图12D为本申请实施例提供的又一种显示示意图；

图12E为本申请实施例提供的又一种显示示意图；

图12F为本申请实施例提供的又一种显示示意图；

图13为本申请实施例提供的又一种信号交互示意图；

图14A为本申请实施例提供的又一种显示示意图；

图14B为本申请实施例提供的又一种显示示意图；

图14C为本申请实施例提供的又一种显示示意图；

图14D为本申请实施例提供的又一种显示示意图；

图14E为本申请实施例提供的又一种显示示意图；

图14F为本申请实施例提供的又一种显示示意图；

图15为本申请实施例提供的又一种信号交互示意图；

图16A为本申请实施例提供的又一种显示示意图；

图16B为本申请实施例提供的又一种显示示意图；

图16C为本申请实施例提供的又一种显示示意图；

图16D为本申请实施例提供的又一种显示示意图；

图16E为本申请实施例提供的又一种显示示意图；

图17A为本申请实施例提供的又一种信号交互示意图；

图17B为本申请实施例提供的又一种显示示意图；

图17C为本申请实施例提供的又一种显示示意图；

图17D为本申请实施例提供的又一种显示示意图；

图18A为本申请实施例提供的又一种显示示意图；

图18B为本申请实施例提供的又一种显示示意图；

图18C为本申请实施例提供的又一种显示示意图；

图18D为本申请实施例提供的又一种显示示意图；

图19为本申请实施例提供的又一种信号交互示意图；

图20为本申请实施例提供的又一种信号交互示意图；

图21为本申请实施例提供的又一种信号交互示意图；

图22为本申请实施例提供的又一种信号交互示意图；

图23为本申请实施例提供的一种芯片系统的结构示意图。

具体实施方式

本申请实施例涉及的系统架构可以包括多个电子设备，多个电子设备之间可以进行组网，组网后多个电子设备之间可以进行信息交互。组网方式包含不限于以下方式：

(1)、无线保真(wireless fidelity，Wi-Fi)组网方式：多个电子设备可以接入同一个路由设备(例如，路由器)。如图1所示，手机101、手机102、平板电脑103、笔记本电脑104、智慧电视105可以接入路由器106，组成一个家庭网络。或者，多个电子设备可以加入同一个热点设备(例如，接入同一个手机的热点)，此时电子设备和电子设备之间的信息交互，可以通过热点设备转发。例如，手机102、平板电脑103、笔记本电脑104、智慧电视105可以接入手机101，组成一个热点网络，手机101可以作为热点设备为各个电子设备转发信息。

(2)、蓝牙组网方式：多个电子设备可以连接到同一个蓝牙设备(例如，手机104)，此时电子设备和电子设备之间的信息交互，可以通过蓝牙设备转发。如图2所示，手机101、平板电脑103、笔记本电脑104、智慧电视105可以接入手机102，组成一个蓝牙网络，手机104可以作为蓝牙设备为各个电子设备转发信息。

多个电子设备可以采用多种组网方式，例如，同时采用无线保真组网方式和蓝牙组网方式，本申请不做限定。

如图3所示，本申请实施例以电子设备200(如手机)为例，对本申请实施例提供的电子设备的结构进行举例说明。电子设备200(如手机)可以包括：处理器210，外部存储器接口220，内部存储器221，通用串行总线(universal serial bus，USB)接口230，充电管理模块240，电源管理模块241，电池242，天线1，天线2，移动通信模块250，无线通信模块260，音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，传感器模块280，按键290，马达291，指示器292，摄像头293，显示屏294，以及用户标识模块(subscriberidentification module，SIM)卡接口295等。

其中，上述传感器模块280可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器和骨传导传感器等传感器。

可以理解的是，本实施例示意的结构并不构成对电子设备200的具体限定。在另一些实施例中，电子设备200可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器210可以包括一个或多个处理单元，例如：处理器210可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

控制器可以是电子设备200的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器210中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器210中的存储器为高速缓冲存储器。该存储器可以保存处理器210刚用过或循环使用的指令或数据。如果处理器210需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器210的等待时间，因而提高了系统的效率。

在一些实施例中，处理器210可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备200的结构限定。在另一些实施例中，电子设备200也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块240用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。充电管理模块240为电池242充电的同时，还可以通过电源管理模块241为电子设备供电。

电源管理模块241用于连接电池242，充电管理模块240与处理器210。电源管理模块241接收电池242和/或充电管理模块240的输入，为处理器210，内部存储器221，外部存储器，显示屏294，摄像头293，和无线通信模块260等供电。在一些实施例中，电源管理模块241和充电管理模块240也可以设置于同一个器件中。

电子设备200的无线通信功能可以通过天线1，天线2，移动通信模块250，无线通信模块260，调制解调处理器以及基带处理器等实现。在一些实施例中，电子设备200的天线1和移动通信模块250耦合，天线2和无线通信模块260耦合，使得电子设备200可以通过无线通信技术与网络以及其他设备通信。

天线1和天线2用于发射和接收电磁波信号。电子设备200中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块250可以提供应用在电子设备200上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块250可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块250可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。

移动通信模块250还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块250的至少部分功能模块可以被设置于处理器210中。在一些实施例中，移动通信模块250的至少部分功能模块可以与处理器210的至少部分模块被设置在同一个器件中。

无线通信模块260可以提供应用在电子设备200上的包括WLAN(如(wirelessfidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigationsatellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(nearfield communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。

无线通信模块260可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块260经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器210。无线通信模块260还可以从处理器210接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

电子设备200通过GPU，显示屏294，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏294和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器210可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏294用于显示图像，视频等。该显示屏294包括显示面板。

电子设备200可以通过ISP，摄像头293，视频编解码器，GPU，显示屏294以及应用处理器等实现拍摄功能。ISP用于处理摄像头293反馈的数据。摄像头293用于捕获静态图像或视频。在一些实施例中，电子设备200可以包括1个或N个摄像头293，N为大于1的正整数。

外部存储器接口220可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备200的存储能力。外部存储卡通过外部存储器接口220与处理器210通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器221可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令，从而执行电子设备200的各种功能应用以及数据处理。例如，在本申请实施例中，处理器210可以通过执行存储在内部存储器221中的指令，内部存储器221可以包括存储程序区和存储数据区。

其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备200使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器221可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universalflash storage，UFS)等。

电子设备200可以通过音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

按键290包括开机键，音量键等。按键290可以是机械按键。也可以是触摸式按键。马达291可以产生振动提示。马达291可以用于来电振动提示，也可以用于触摸振动反馈。指示器292可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。SIM卡接口295用于连接SIM卡。SIM卡可以通过插入SIM卡接口295，或从SIM卡接口295拔出，实现和电子设备200的接触和分离。电子设备200可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口295可以支持Nano SIM卡，Micro SIM卡，SIM卡等。

如图4所示，对本申请实施例提供的电子设备的软件结构进行举例说明。电子设备的软件架构可以包括应用层、应用框架层、硬件抽象层(hardware abstraction layer，HAL)和驱动层。本申请实施例以电子设备的操作系统是双框架操作系统(即安卓系统和鸿蒙系统)为例进行说明。电子设备也可以是安卓系统、鸿蒙系统、IOS系统或者其他操作系统，本申请实施例不做限定。

其中，应用层可以包括安卓应用和鸿蒙应用。其中，安卓应用可以包括设备管理(device manager)kit和分布式执行框架(distributed execute framework，DEF)kit。其中，kit(服务)可以是一种用于向应用层(的应用程序)提供基础服务的软件开发工具包(software development kit，SDK)。DM kit可以包括设备发现模块、可信设备维护模块、设备认证模块、设备筛选、排序模块等。鸿蒙应用可以包括DM kit和鸿蒙SDK。其中，SDK可以是指辅助开发某一类软件的相关文档、范例和工具的集合。

其中，DM kit可以包括设备发现模块、可信设备维护模块、设备认证模块、设备筛选、排序模块等。可选的，应用层还可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序，本申请不做限定。

应用框架层可以包括DM、DEF、分布式调度管理服务(distributed schedulermanager Service，DMS)、二维码识别模块(hivision)、鸿蒙标签管理模块、安全管理模块、通信模块、设备信息数据库(device profile)。当然，框架层302还可以包括活动管理器、窗口管理器，内容提供器，资源管理器，通知管理器等，本申请实施例对此不做任何限制。

其中，设备管理模块(DM模块)：主要提供设备发现，可信设备维护以及设备认证能力。通过维护本地设备信息，将信息写入二维码，扫码识别，建立物理连接以及维护设备群组信息来对同账号或异账号设备之间，安卓与鸿蒙设备之间建立安全可信的连接。可选的，DM中可以包括设备发现模块、可信设备维护模块、设备认证模块和设备排序、筛选模块。设备发现模块用于进行发送广播、发现设备、设备信息封装和设备列表弹框UI等处理。可信设备维护模块用于进行查询可信设备列表、写入可信设备信息、可信设备列表维护、监听可信设备上下线等处理。设备认证模块用于进行底层通道管理、访问控制、PIN码机制和群组管理等处理。设备排序、筛选模块用于进行设备筛选、设备排序等处理。

鸿蒙标签管理模块：负责提供鸿蒙标签申请、解析、格式化，鸿蒙标签服务查询以及服务分发能力。

分布式执行框架(DEF)：负责提供原子化服务的发现，注册，查询，迁移；负责设备之间底层数据通信和设备发现。

二维码识别模块：提供鸿蒙标签生成以及扫码能力，通过标签服务提供的标签信息生成鸿蒙二维码标签，通过扫描鸿蒙二维码标签触发标签服务解析标签信息。

安全管理模块(HiChain)：管理分布式场景下的群组，以及设备群组认证；群组包括公共群组和应用级私有群组。提供分布式场景下设备与设备间，应用与应用间的安全可信通信和连接。

通信模块(communication)：软总线管理分布式场景下同账号设备的自发现，自组网；扫描发现不同账号的设备；为不同设备间的通信提供通道，保障数据的安全稳定传输。

DMS：主要完成跨设备的服务绑定，以及跨设备的Android接口定义语言(androidinterface definition language，AIDL)接口调用能力。AIDL是用于定义服务器和客户端通信接口的一种描述语言。

设备信息数据库：负责设备信息的读写，存储与管理。

HAL可以包括麦克风、扬声器、Wi-Fi模组、蓝牙模组、摄像头、传感器等。

驱动层是硬件和软件之间的层，也可以称为内核层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

上述软件架构可以部署在当前组网环境内的多个电子设备上(例如，如图1或图2中的手机101、手机102、平板电脑103、笔记本电脑104、智慧电视105、路由器106等等)。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请的描述中，除非另有说明，“至少一个”是指一个或多个，“多个”是指两个或多于两个。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

为了下述各实施例的描述清楚简洁，首先给出相关概念或技术的简要介绍：

Ability：Ability是应用所具有的能力的抽象，一个应用可以包含一个或者多个Ability。HarmonyOS支持应用以Ability为单位进行部署。Ability分为两种类型：FA(特性能力)和AA(元能力)。

AA：由三方基于鸿蒙系统服务开发，实现单一功能的程序实体，用于提供后台运行任务的能力，无UI界面。AA具有多端部署、分布执行的特性。AA对系统服务有依赖关系，AA之间不存在依赖关系。

FA：用于提供与用户交互的能力(功能)。一个FA可以包含一组相关页面(也可以认为是一组UI)，每个页面可以用一个AbilitySlice实例表示。FA可以通过调用AA实现复杂功能的程序实体，基于新的界面/数据/逻辑分离的结构开发，可以独立打包和上架。FA具有以下能力：免安装，脱离应用独立运行、跨设备UI迁移、跨设备二进制迁移等能力。FA与小程序或快应用的UI界面有部分类似，但实质上是不同的。其区别可以包括两点，一是FA可以跨设备迁移(例如，可以将手机A的FA迁移到手机B，这样手机B可以控制手机A的该FA)；二是FA可以跨平台，例如，FA既可以运行在安卓系统，也可以运行在鸿蒙系统，目前的小程序或快应用通常运行在安卓系统。

目前，可以采用FA分享技术在不同设备之间分享FA，即可以将一个设备的FA迁移至另一个设备进行展示和操作。在分享FA之前，需要进行认证，保证FA分享的安全可靠。

本申请实施例提供一种功能迁移方法，包括设备级认证和应用级认证。不同设备之间经过应用级认证后，不同设备间的特定应用可以实现互通(即应用之间可以交换业务数据，例如迁移FA)。例如，设备A的第一应用和设备B的第一应用相互认证后，设备A的第一应用和设备B的第一应用可以实现互通，但设备A的其他应用(例如第二应用)和设备B的其他应用(例如第二应用)之间不互通。经过设备级认证后，不同设备间的所有应用可以实现互通。

为了便于理解，以下以手机A和手机B为例，对本申请实施例提供的设备级认证的用户界面(user interface，UI)界面进行介绍。

如图5A中的(a)所示，用户可以从设置应用进入智慧协同界面501，智慧协同界面501可以包括名称为“我的设备”的列表。其中，“我的设备”包括本机(即手机A)、kiki’sMate pad和kiki’s Mate book pro。本机、kiki’s Mate pad和kiki’s Mate book pro可以是同账号(例如，共用一个华为账号)的设备。或者，本机、kiki’s Mate pad和kiki’s Matebook pro可以是异账号但经过认证(认证过程可以参考下文的相关描述)的设备。

可选的，智慧协同界面501可以包括绑定其他设备按钮502。本申请实施例中，绑定是指两个设备间建立可信关系，从而两个设备的任意应用之间可以实现互通，例如可以相互迁移FA，无需认证。响应于用户对绑定其他设备按钮502的操作(例如，点击操作)，如图5A中的(b)所示，手机A可以显示碰一碰添加按钮503和扫一扫添加按钮504。应该理解的是，图5A中的(a)和(b)分别对应的UI界面中的各个元素(例如，按钮、图标、文字等)的位置、名称和形状等不是固定不变的，可以根据需求进行自由组合或设计。例如，可以将图5A中的(a)中的按钮502可以替换为图5A中的(b)中的按钮503和按钮504。

例如，响应于用户对碰一碰添加按钮503的点击操作，如图5B中的(a)所示，手机A可以显示碰一碰添加界面505，碰一碰添加界面505中可以显示弹框506，弹框506中包括提示图画和提示信息，提示信息例如可以是：“碰一碰添加，手机开启NFC后，用背面碰一碰设备上的ontag标签”。用户可以根据提示信息进行操作，以便通过碰一碰的方式添加新的设备。又例如，响应于用户对扫一扫添加按钮504的点击操作，如图5B中的(b)所示，手机A可以显示扫一扫添加界面507，扫一扫添加界面507中可以包括提示图画和提示信息，提示信息例如可以是：“扫描设备或包装上的二维码”。用户可以根据提示信息进行操作，以便通过扫一扫的方式添加新的设备。

若手机A不支持通过碰一碰和扫一扫的方式添加新的设备，如图5C中的(a)所示，响应于用户点击绑定其他设备按钮502的操作，如图5C中的(b)所示，手机A可以显示弹框508，弹框508中包括提示信息“请确保设备已开启，且位于手机附近”，弹框508中还可以包括手机A基于短距通信网络(例如，Wi-Fi网络或蓝牙网络)检测到的设备，例如房间电视、HUAWEI P20和Mate book X pro等设备。每个设备对应一个绑定按钮。响应于用户对HUAWEIP20对应的绑定按钮509的操作，如图5D中的(a)所示，HUAWEI P20的标识下方可以显示提示信息510“等待对端确认...”。弹框508中还可以取消按钮511，响应于用户点击取消按钮511的操作，手机A可以返回如图5C中的(a)所示的界面。

若对端设备确认(例如，对端设备的用户同意绑定)，如图5D中的(b)所示，手机A可以显示绑定新设备界面512，绑定新设备界面512中可以包括提示信息“扫一扫对端显示的二维码”，用户可以根据提示信息进行操作，以便添加新的设备。应该理解的是，本申请实施例不限定不同UI界面的跳转关系。例如，如图5C中的(b)所示，响应于用户点击绑定按钮509的操作，如图5D中的(b)所示，手机可以直接显示扫描界面512。

若对端设备未确认(例如，对端设备不具备绑定功能，绑定超时，或者对端设备正忙，或者对端设备的用户不同意绑定)，如图5E中的(a)所示，手机A可以显示弹框521，提示用户“设备认证失败”，响应于用户点击知道按钮522的操作，弹框521可以隐去。或者，弹框521可以在预设时间(例如，3s)后隐去。在另一种可能的设计中，如图5E中的(b)所示，手机A可以显示弹框523，提示用户“对端正忙，请稍后发起绑定”，响应于用户点击知道按钮524的操作，弹框523可以隐去。或者，弹框523可以在预设时间(例如，3s)后隐去。在又一种可能的设计中，如图5E中的(c)所示，手机A可以显示弹框525，提示用户“对端拒绝信任此设备，绑定失败”，响应于用户点击知道按钮526的操作，弹框525可以隐去。或者，弹框525可以在预设时间(例如，3s)后隐去。或者，如图5F所示，手机A可以在界面512中显示弹框527，提示用户“对端二维码已关闭，无法完成设备认证，绑定失败”。响应于用户点击知道按钮528的操作，弹框527可以隐去。

假设对端设备是手机B(例如可以是HUAWEI P20)，若手机B在显示桌面530时接收到手机A的绑定请求，如图6A中的(a)所示，手机B可以显示弹框531，弹框531中可以包括提示信息532“HUAWEI MATE30请求绑定本机，是否信任此设备”，弹框531中还可以包括不信任按钮533和信任按钮534。不信任按钮中还可以显示倒计时(例如，14s)，倒计时结束时若用户未点击任何按钮可以自动隐去弹框531。响应于用户点击信任按钮534的操作，手机A可以与手机B进行认证过程(参考下文关于步骤718A-步骤732的相关描述)，从而手机A可以绑定手机B。

若手机B在息屏状态或锁屏状态下接收到手机A的绑定请求，如图6A中的(b)所示，手机B可以在锁屏界面535中显示弹框536，弹框536可以提示用户智慧协同应用在上午7:30接收到设备绑定请求，具体可以是“HUAWEI MATE30(即手机A)请求绑定本机，是否信任此设备？”响应于用户从锁屏状态进入桌面的操作(例如，输入密码或输入指纹)，如图6A中的(a)所示，弹框536可以变更为弹框531的形式，用户可以选择信任或不信任HUAWEI MATE30(即手机A)。

若手机B在视频播放或游戏状态下接收到手机A的绑定请求，如图6B中的(a)所示，手机B可以在视频界面或游戏界面540中显示弹框541，弹框541可以提示用户智慧协同应用接收到设备绑定请求，具体可以是“HUAWEI MATE30请求绑定本机，是否信任此设备？”。响应于用户点击下拉控件542的操作，如图6B中的(b)所示，弹框541可以展示更多信息，例如可以显示不信任按钮543和信任按钮544。不信任按钮543中还可以显示倒计时(例如，14s)，倒计时结束时若用户未点击任何按钮可以自动隐去弹框541。响应于用户点击信任按钮544的操作，手机A可以与手机B进行认证过程(参考下文关于步骤718A-步骤732的相关描述)。

在一种可能的设计中，响应于用户点击信任按钮的操作，如图6C所示，手机B可以返回桌面530，且显示弹框550，弹框550中可以包括手机B生成的二维码551，还可以包括提示信息552“扫一扫绑定，允许HUAWEI MATE30扫一扫绑定本机”。此时，手机A的用户可以用手机A扫描手机B显示的二维码，以便手机A与手机B进行绑定。弹框550中还可以包括取消按钮553，响应于用户点击取消按钮553的操作，弹框550可以隐去。

在一些实施例中，若手机A和手机B登录了同一个账号(例如，华为账号)，手机A可以直接与手机B绑定(例如，如图5C中的(b)，在手机A上点击手机B(HUAWEI P20)对应的绑定按钮)，无需等待手机B确认(例如，无需如图5D中的(a)一样等待对端确认，也无需如图5D中的(b)一样扫描对端显示的二维码)。

下面以手机A和手机B为例，对本申请实施例提供的设备级认证方法的具体实现方式进行说明。其中，手机A和手机B为异账号设备。如图7A所示，包括：

701、用户在手机A上触发绑定手机B的操作。

例如，用户可以在手机A上点击手机B对应的绑定按钮。例如，如图5C中的(b)所示，响应于用户在手机A上点击手机B(HUAWEI P20)对应的绑定按钮509的操作，手机A执行步骤702。

702、手机A的设置应用向手机A的DM发起绑定请求。

其中，设置应用是指名称为“设置”的应用程序，该设置应用用于对手机A的基础功能进行配置，例如可以用于网络配置、显示和亮度配置、声音和振动配置、应用管理配置等。

其中，绑定请求中携带的信息可以包括手机A的名称(例如，HUAWEI MATE30)。

703、可选的，手机A的DM收到设置应用发送的绑定请求后，向手机A的设备信息数据库请求已认证设备的信息。

手机A的DM可以从设备信息数据库中读取已认证过的设备的信息。设备信息数据库中存储有已与手机A认证过的设备的信息。其中，认证过的设备的信息可以包括设备名称和设备ID。设备ID例如可以是国际移动设备识别码(international mobile equipmentidentity，IMEI)。示例性的，与手机A认证过的设备的信息可以如表1所示。

表1

设备名称	设备ID(IMEI)
		kiki’s Mate pad	123456XXXXXXX
kiki’s Mate book pro	654321XXXXXXX

704、可选的，手机A的设备信息数据库向手机A的DM返回已认证设备的信息。

在一种可能的设计中，当手机A与手机B相互认证后，已认证设备的信息可以包括手机B的信息。

应该理解的是，在手机A与手机B进行设备级认证时，步骤703和步骤704是可选的。若执行步骤703和步骤704，即若获取到已认证设备的信息，手机A可以向用户展示已认证设备。已认证设备可以默认是绑定状态，或者，可以对已认证设备重新进行绑定。

步骤703和步骤704是手机A的DM获取已认证设备的信息的一种示意的实现方式，手机A的DM还可以通过其他方式获取已认证设备的信息(例如，从预设存储空间读取已认证设备的信息)，本申请不做限定。

705、手机A的DM向手机A的通信模块请求附近设备的信息。

设备管理可以通过一个常驻服务调用设备A的通信模块持续向周边发送广播，这样设备管理可以通过注册广播监听服务来发现近场全量设备(即近场通信下的全部设备，其中，近场通信可以包括无线保真通信、蓝牙通信等)。再结合从设备信息数据库中读取的已认证过的设备的信息，DM可以以图标的形式分类展示近场全量设备中的已认证设备(如图5C中的(a)所示的kiki’s Mate pad，kiki’s Mate book pro等)和未认证设备(如图5C中的(b)所示的房间电视，HUAWEI P20和Mate book X pro等)。

需要说明的是，步骤703和步骤705之间没有必然的执行先后顺序，本实施例对此不作具体限定。

706、手机A的通信模块向手机A的DM返回附近设备的信息。

707、手机A的DM弹出附近设备列表。

如图5C中的(b)所示，手机A的DM可以调用弹框能力，从而在手机A的显示屏弹出弹框508(即附近设备列表)，弹框508中包括房间电视，HUAWEI P20和Mate book X pro等附近设备。

708、用户选择需要绑定的设备。

例如，如图5C中的(b)所示，用户可以从附近设备列表中选择需要绑定的设备，例如用户可以选中HUAWEI P20(即手机B)。

709、手机A的DM向手机A的通信模块请求创建底层通道。

底层通道可以是蓝牙通道或Wi-Fi通道等，本申请不做限定。

710、手机A的通信模块与手机B的通信模块进行信息交互，创建底层通道。

711、可选的，手机A的通信模块向手机A的DM发送创建成功通知。

即手机A的通信模块向手机A的DM发送底层通道创建成功通知，表示手机A的通信模块与手机B的通信模块之间成功创建底层通道。

应该理解的是，在手机A与手机B进行设备级认证时，步骤711是可选的。若执行步骤711，后续手机A的DM可以及时获知底层通道创建成功，以便后续可以通过底层通道传输数据。或者，也可以基于其他方式获知底层通道创建成功，例如，经过预设时间未收到底层通道创建失败的通知，可以认为底层通道创建成功。

712、手机A的DM通过手机A的通信模块向手机B发送认证请求消息。

其中，认证请求消息可以包括手机A的标识(例如，名称或ID)和手机A生成的身份认证信息，手机A生成的身份认证信息可以包括手机A生成的令牌(token)。手机A的名称例如可以是HUAWEI MATE30。token例如可以是若干位的随机字符串。

其中，token可以用于身份认证。本申请实施例中，手机A可以向手机B发送token，token可以是手机A的设备号/设备mac地址，也可以是用来确定手机A的其它标识。当手机B接收到手机A的token后，可以将该token的信息加入到手机B后续生成二维码图片中，使得该二维码图片只能被手机A所使用。

如图7B所示，上述方法还包括：

713、可选的，手机B的通信模块向手机B的DM发送创建成功通知。

即手机B的通信模块向手机B的DM发送底层通道创建成功通知，表示手机B的通信模块与手机A的通信模块之间成功创建底层通道。

应该理解的是，在手机A与手机B进行设备级认证时，步骤713是可选的。若执行步骤713，后续手机B的DM可以及时获知底层通道创建成功，以便后续可以通过底层通道传输数据。或者，也可以基于其他方式获知底层通道创建成功，例如，经过预设时间未收到底层通道创建失败的通知，可以认为底层通道创建成功。

需要说明的是，步骤711和步骤713之间没有必然的执行先后顺序，本实施例对此不作具体限定。

714、手机A的通信模块向手机B的通信模块发送认证请求消息。

手机A的通信模块可以通过底层通道向手机B的通信模块发送认证请求消息。

715、手机B的通信模块将认证请求消息转发给手机B的DM。

可以理解的是，步骤712、步骤714和步骤715用于描述手机A向手机B发送认证请求消息的过程。手机A的DM与手机B的DM需要分别通过手机A的通信模块和手机B的通信模块进行通信，当然，手机A的DM与手机B的DM也可以通过其他模块通信，或者，手机A的DM与手机B的DM可以具有通信能力直接可以进行通信，本申请不做限定。

716、可选的，手机B的DM通过弹窗通知用户是否同意绑定。

示例性的，如图6A中的(a)所示，手机A可以弹出弹框531，弹框531中可以包括提示信息532“HUAWEI MATE30请求绑定本机，是否信任此设备”，弹框531中还可以包括不信任按钮533和信任按钮534。

717、可选的，手机B接收用户同意绑定的操作。

例如，如图6A中的(a)所示，用户点击信任按钮534可以表示用户同意绑定。

若用户同意(例如，如图6A中的(a)所示，若用户点击信任按钮534)，手机B的DM可以通过通信模块将用户同意的信息返回给手机A的DM，手机A可以提示用户主动扫描对端(手机B)显示的二维码(二维码图片)。

另外，若用户不同意(例如，若用户点击不信任按钮533)，手机B的DM可以通过通信模块将用户不同意的信息返回给手机A的DM，手机A可以显示如图5E中的(c)所示的提示信息，绑定失败。

应该理解的是，在手机A与手机B进行设备级认证时，步骤716和步骤717可以是可选的。例如，若手机A与手机B登录了同一个账号，或者设置了亲情号码等服务，手机B可以不向用户请求是否同意绑定，直接执行步骤718A及其后续的必要步骤。

步骤716和步骤717是手机B提示用户是否同意绑定的一种实现方式，手机B还可以通过其他方式提示用户，例如通过后台系统通知消息通知，本申请不做限定。

718A、手机B的DM判断手机B是否建立过与手机A相关的群组。

手机B的DM可以从手机B的HiChain中查询手机B是否建立过与手机A相关的公共群组。其中，手机B的HiChain可以存储手机B建立过的全部群组信息，包括公共群组和私有群组。其中，公共群组可以是指以设备为粒度建立的群组，例如两个设备属于一个公共群组表示两个设备经过设备级的认证，两个设备之间的所有应用可以安全互通。私有群组是指以设备和应用为粒度建立的群组，例如，第一设备的第一应用可以与第二设备的第二应用进行应用级认证。经过应用级认证后，第一应用与第二应用属于一个私有群组，此时第一应用与第二应用可以安全互通(例如，可以安全分享数据)。第一应用与第二应用的标识可以相同或不相同，本申请不对此进行限定。两个设备分别对应的一个应用属于一个私有群组表示该两个设备经过应用级的认证，两个设备分别对应的特定应用之间可以安全互通。示例性的，手机B建立过的全部群组信息可以如表2所示：

表2

公共群组	私有群组
		群组1(手机B，手机C)	群组3(手机B的应用1，手机D的应用2)
群组2(手机B，手机D)	群组4(手机B的应用1，手机E的应用3)

可选的，表2中的群组1和群组2可以组合成一个包括3个成员的群组，例如群组5(手机B，手机C，手机D)。这样，手机A可以从群组5中查找与手机A进行过设备级认证的设备，无需遍历两两设备之间建立的公共群组。

可选的，表2中的群组3和群组4可以组合成一个包括3个成员的群组，例如群组6(手机B的应用1，手机D的应用2，手机E的应用3)。这样，手机A可以从群组6中查找与手机A进行过应用级认证的设备的应用，无需遍历两两应用之间建立的私有群组。

718B、如果手机B未建立过与手机A相关的群组，手机B的DM向手机B的安全管理模块请求创建群组。

手机B的安全模块创建一个关于手机A的群组，群组名为手机A和手机B的设备ID。进一步可以设置手机A和手机B之间的群组属性为公共，即手机A和手机B之间的所有应用可以互通。

718C、手机B的安全管理模块向手机B的DM发送群组创建成功通知。

应该理解的是，步骤718B和步骤718C是一种示意的创建群组的方式，本申请不限定其他创建群组的方式，例如，手机B的DM可以直接创建群组。

719、手机B的DM向手机B的鸿蒙标签管理模块请求标签。

手机B的鸿蒙标签管理模块可以生成标签，标签中包括认证校验信息以及手机B的会话标识，认证校验信息可以包括从手机A接收的token。或者，可以认为认证校验信息包括从手机A接收的token和手机B的会话标识。手机B的会话标识中包括手机B的设备连接信息。例如，手机B的会话标识包括手机B的Wi-Fi地址(例如，IP地址和端口(Port)号)或者蓝牙地址。

认证校验信息中还可以包括群组对应的个人识别密码PIN。PIN例如可以是若干位随机数字，例如可以为6位或8位随机数字等。本申请实施例中，手机B可以向手机A发送群组对应的PIN。当手机A需要加入手机B创建的群组时，可以在请求中携带群组对应的PIN。手机B确定手机A携带的PIN是正确的(即是手机B发送给手机A的)，认为手机A是安全可信的，允许手机A加入手机B创建的群组。

720、手机B的鸿蒙标签管理模块向手机B的二维码识别模块请求认证校验信息的二维码图片(BitMap)。

手机B的二维码识别模块可以根据认证校验信息组装二维码图片。需要说明的是，上述实施例以二维码图片为标识符进行示意说明，可以将二维码图片替换为其他类型的标识符，例如条形码、字符串等，本申请不做限定。

721、手机B的二维码识别模块向手机B的鸿蒙标签管理模块返回二维码图片。

722、手机B的鸿蒙标签管理模块向手机B的DM返回二维码图片。

723a、可选的，手机B的DM向手机B的通信模块发送二维码图片。

在一种可能的设计中，手机B的DM可以通过手机B的通信模块将手机B的二维码图片发送给手机A，以便手机A对该二维码图片进行内部扫描，即在步骤723a之后，可以执行步骤723b-步骤725。在另一种可能的设计中，手机B可以将手机B的二维码图片显示在手机B的显示界面(如图6C所示的显示界面)，以便手机A直接扫描，从而使得手机A中的二维码识别模块可以直接获取手机B生成的二维码图片，从而跳过步骤723b-步骤725。上述两种设计均可以实现本方案的技术效果，本申请不对此进行限定。

723b、可选的，手机B的通信模块向手机A的通信模块发送二维码图片。

手机A的DM可以拉起二维码识别模块，通过二维码识别模块扫描手机B生成的二维码图片。

如图7C所示，上述方法还包括：

724、可选的，手机A的通信模块向手机A的DM发送二维码图片。

725、可选的，手机A的DM向手机A的二维码识别模块发送二维码图片。

726、手机A的二维码识别模块扫描二维码图片，将识别到的信息发送给手机A的鸿蒙标签管理模块。

727、手机A的鸿蒙标签管理模块解析二维码识别模块发送的信息，得到解析结果。

其中，解析结果可以包括token、PIN和手机B的会话标识等信息。

728、手机A的鸿蒙标签管理模块向手机A的DM发送解析结果。

可以理解的是，步骤724-步骤728是手机A处理二维码图片的一种示意的实现方式，手机A还可以通过其他方式处理二维码图片，本申请不做限定。例如，手机A的DM可以集成二维码图片处理功能，这样手机A的DM可以直接扫描和解析二维码图，以得到token、PIN和手机B的会话标识等信息。

729、手机A的DM校验token。

若从手机B接收到的token与认证请求消息中携带的token相同，执行步骤730。

730、手机A的DM回调认证成功。

应该理解的是，在手机A与手机B进行设备级认证时，步骤729和步骤730是可选的。若执行步骤729和步骤730，即若手机A的DM校验token，可以更好地保证手机A和手机B通信的安全性。

731、手机A加入手机B创建的公共群组。

手机A的DM根据会话标识确定手机B的Wi-Fi地址或者蓝牙地址，向手机A的安全模块申请加入手机B创建的群组。

手机A的安全模块利用Wi-Fi地址或蓝牙地址创建底层通信通道，并向手机B发送加入群组请求，加入群组请求中可以包括群组ID。可选的，加入群组请求中还可以包括PIN。手机B接收到加入群组请求，可以校验PIN，认证通过(即该PIN与二维码图片中的PIN相同)后，两个设备加入同一个群组(该群组的群组成员可以包括手机A和手机B，该群组的属性为公共)，完成认证。

在一种可能的实现方式中，当手机B接收到加入群组请求并认证通过后，会向手机A发送一个响应消息，该响应消息指示手机A已加入手机B创建的公共群组。

732、手机A的安全管理模块通知应用程序(设置应用)认证成功。

手机A可以在本地保存群组的信息。群组的信息可以群组成员(该群组的群组成员可以包括手机A和手机B)，群组的信息还可以包括群组的群组名和属性信息(例如，属性为公共)。

这样，手机A和手机B之间完成了设备级认证，手机A和手机B间的所有应用可以实现互通。例如，手机A的直播应用、K歌应用、购物应用和邮件应用可以和手机B的直播应用、K歌应用、购物应用和邮件应用之间互通。

在一些实施例中，若手机A和手机B中的一个登录了账号(例如，华为账号)，另一个没有登录账号，手机A和手机B可以执行上述步骤701-步骤732的全部或者部分步骤。以便在手机A和手机B绑定时进行验证(即进行设备级认证)，以保证设备间的数据的安全。

在一些实施例中，若手机A和手机B都没有登录账号(例如，华为账号)，手机A和手机B可以执行上述步骤701-步骤732。以便在手机A和手机B绑定时进行验证，以保证设备间的数据的安全。

在一些实施例中，若手机A和手机B登录了同一个账号(例如，华为账号)，手机A和手机B可以执行上述步骤701-步骤732。以便在手机A和手机B绑定时进行验证，进一步保证设备间的数据的安全。

需要说明的是，上述步骤701-步骤732中的部分步骤可以是可选的，即不是设备级认证方案的必要技术特征。例如，步骤703和步骤704可以是可选的步骤，即可以不查询已认证设备，直接查看周边的设备。又例如，步骤711和步骤713可以是可选的步骤，即可以不发送创建成功通知。又例如，步骤716和步骤717可以是可选的步骤，即可以不经过用户同意，直接绑定。又例如，步骤723b-步骤725可以是可选的步骤，此时手机A可以直接获取手机B生成的二维码图片(例如，通过扫描手机B显示的二维码图片)。

若设备之间未进行设备级认证，设备间的应用可以进行应用级认证，从而使得特定应用之间可以互通。下面结合具体的场景，以直播应用为例，对本申请实施例提供的应用级认证的UI界面进行介绍。

随着电商的发展，越来越多的人关注到直播卖货这种销售新渠道。直播卖货不仅要求带货设备拍摄清晰，拾音准确，还要有更佳的交互体验。直播卖货当前的一个痛点是在同一个镜头下无法同时展示主播和清晰的商品细节，导致电商秀导展示的真实感、认同感降低。

本申请针对直播业务，提供了一种基于跨设备FA分享的分布式展示方案，例如可以将手机A的直播画面(设备A的直播画面可以认为是一个FA，例如FA1)分享至手机B，手机B可以同时显示手机A的FA和手机B的直播画面(设备B的直播画面可以认为是一个FA，例如FA2)，达到跨设备展示一个或多个FA的体验，省去用户来回切换终端的繁琐，大大减少了用户操作。本申请不要求设备之间满足同系统的要求，也不要求设备登录同一个设备账号(例如，同一个华为账号)，适用范围广。

示例性的，如图8A所示，用户在手机A打开直播应用后，手机A可以显示直播界面801，直播界面801可以包括迁移按钮802，迁移按钮802位于界面801的左上角。应该理解的是，迁移按钮802也可以位于界面801的左下角、右下角、右上角等位置，本申请不做限定。当然，按钮802上显示的文字也可以是其他内容，例如可以是共享、转移等，本申请不做限定。响应于用户在直播界面801点击迁移按钮802(迁移按钮802用于将手机A的直播界面迁移(发送)至其他设备(例如，手机B))的操作，如图8B中的(a)所示，手机A可以弹出弹框803。应该理解的是，本申请实施例不限定UI界面之间的跳转方式。例如，如图8A所示，响应于用户特定手势(例如，三指下滑、指关节敲击等)的操作，如图8B中的(a)所示，手机可以显示弹框803。其中，弹框803中可以包括附近的设备，附近的设备包括已认证设备(卧室电视，monica’s Mate pad等)和未认证设备(房间电视，HUAWEI P20和Mate book X pro等)。响应于用户点击HUAWEI P20(未认证过的设备)对应的控件804的操作，手机A可以向手机B发送认证请求消息。并且，如图8B中的(b)所示，在HUAWEI P20的下方可以显示提示信息805“等待对端确认”。如图8C中的(a)所示，若手机B(HUAWEI P20)在显示直播界面811时，接收到手机A发送的认证请求消息，手机B可以显示弹框812，弹框812中包括提示信息“HUAWEIMATE30(手机A)请求将直播界面迁移到本机，是否同意”，响应于用户点击下拉按钮813的操作，如图8C中的(b)所示，弹框812可以显示更多内容，例如显示不同意按钮814和同意按钮815a。可选的，响应于用户点击同意按钮815a的操作，如图8C中的(c)所示，手机可以显示弹框815b，弹框815b中可以包括仅本次同意按钮815c和一直同意(以后不再提示)按钮815d。响应于用户点击同意按钮815a或仅本次同意按钮815c或一直同意按钮815d的操作，如图8D所示，手机B可以显示弹框816，弹框816中可以包括手机B生成的二维码图片，还可以包括提示信息817“扫一扫认证，允许HUAWEI MATE30扫一扫认证”。此时手机A的用户可以扫一扫手机B展示的二维码图片，而后，手机B可以从手机A接收直播画面(FA1)，如图8E所示，手机B可以在直播界面811上显示手机A发送的直播界面819。或者，响应于用户点击同意按钮815的操作，手机B可以从手机A接收直播画面(FA1)，如图8E所示，手机B可以在直播界面811上显示手机A发送的直播界面819。

下面以直播应用为例，对本申请实施例提供的应用级认证方法的具体实现方式进行说明。本申请实施例提供的方法可以应用于两个近场设备，例如手机A和手机B，手机A和手机B为异账号设备(例如，未登录同一个华为账号)，且手机A和手机B都打开了直播应用。如图9A所示，包括：

901、手机A接收用户触发功能迁移的操作。

例如，如图8A所示，用户可以在手机A直播主播的情况下点击迁移按钮802。迁移按钮也可以称为分享按钮、发送按钮等，本申请不做限定。

用户可以通过其他方式触发功能迁移，例如，可以通过“碰一碰”或“扫一扫”的方式触发功能迁移，本申请不做限定。

902、应用程序(例如，直播应用)向手机A的DM发起迁移请求。

其中，迁移请求中携带的信息可以包括发起端的应用程序的标识(本端直播应用包名)，接续端的应用程序的标识(对端直播应用包名)和手机A的名称。其中，接续端包名可以是应用程序(例如，直播应用)给出的，取决于应用厂商对应用程序的设计，在此不做赘述。

在一种可能的设计中，迁移请求中携带的信息可以是根据预设顺序排列的。例如，预设顺序可以依次是手机A的名称、发起端的应用程序的标识和接续端的应用程序的标识。或者，预设顺序可以依次是发起端的应用程序的标识、接续端的应用程序的标识和手机A的名称。

903、可选的，手机A的DM收到迁移请求后，向手机A的设备信息数据库请求已认证的设备。

具体过程可以参考步骤703中的相关描述，在此不做赘述。

904、可选的，手机A的设备信息数据库向手机A的DM返回已认证设备的信息。

应该理解的是，在手机A与手机B进行设备级认证时，步骤903和步骤904是可选的。若执行步骤903和步骤904，即若获取到已认证设备的信息，手机A可以向用户展示已认证设备。

步骤903和步骤904是手机A的DM获取已认证设备的信息的一种示意的实现方式，手机A的DM还可以通过其他方式获取已认证设备的信息(例如，从预设存储空间读取已认证设备的信息)，本申请不做限定。

905、手机A的DM向手机A的通信模块请求附近设备的信息。

具体过程可以参考步骤705中的相关描述，在此不做赘述。

906、手机A的通信模块向手机A的DM返回附近设备的信息。

907、手机A的DM弹出附近设备列表。

附近设备列表例如可以是如图8B中的(a)所示的弹框803。

用户可以从附近设备列表中选择设备，若是不可信设备(即未进行过认证的异账号设备(例如未登录同一个华为账号))，步骤907之后，可以执行步骤908-步骤936，进行应用级认证。若是可信设备((例如，登录了同一个华为账号，或者之前认证(包括设备级认证或应用级认证)过)，则可以直接迁移FA，即步骤907之后，可以直接执行步骤933-步骤936。

908、用户选中未认证设备。

例如，如图8B中的(a)所示，用户选中HUAWEI P20，HUAWEI P20为不可信设备。

909、手机A的DM向手机A的通信模块请求创建底层通道。

底层通道可以是蓝牙通道或Wi-Fi通道等，本申请不做限定。

910、手机A的通信模块与手机B的通信模块进行信息交互，创建底层通道。

911、可选的，手机A的通信模块向手机A的DM发送底层通道创建成功通知。

应该理解的是，在手机A与手机B进行设备级认证时，步骤911是可选的。若执行步骤911，后续手机A的DM可以及时获知底层通道创建成功，以便后续可以通过底层通道传输数据。或者，也可以基于其他方式获知底层通道创建成功，例如，经过预设时间未收到底层通道创建失败的通知，可以认为底层通道创建成功。

912、手机A的DM通过手机A的通信模块向手机B发送认证请求消息。

其中，认证请求消息包括发起端设备名称(例如，HUAWEI MATE30)，发起端包名(例如com.zhibo.video)，接续端包名(例如com.zhibo.video)。认证请求消息还包括手机A生成的token。

如图9B所示，上述方法还包括：

913、可选的，手机B的通信模块向手机B的DM发送底层通道创建成功通知。

需要说明的是，步骤911和步骤913之间没有必然的执行先后顺序，本实施例对此不作具体限定。

应该理解的是，在手机A与手机B进行设备级认证时，步骤913是可选的。若执行步骤913，后续手机B的DM可以及时获知底层通道创建成功，以便后续可以通过底层通道传输数据。或者，也可以基于其他方式获知底层通道创建成功，例如，经过预设时间未收到底层通道创建失败的通知，可以认为底层通道创建成功。

914、手机A的通信模块向手机B的通信模块发送认证请求消息。

认证请求消息中携带的信息可以包括发起端的应用程序的标识，接续端的应用程序的标识和手机A的名称。

在一种可能的设计中，认证请求消息中携带的信息可以是根据预设顺序排列的。例如，预设顺序可以依次是手机A的名称、发起端的应用程序的标识和接续端的应用程序的标识。或者，预设顺序可以依次是发起端的应用程序的标识、接续端的应用程序的标识和手机A的名称。

915、手机B的通信模块将认证请求消息转发给手机B的DM。

可以理解的是，步骤912、步骤914和步骤915用于描述手机A向手机B发送认证请求消息的过程。手机A的DM与手机B的DM需要分别通过手机A的通信模块和手机B的通信模块进行通信，当然，手机A的DM与手机B的DM也可以通过其他模块通信，或者，手机A的DM与手机B的DM可以具有通信能力直接可以进行通信，本申请不做限定。

916、可选的，手机B的DM通过弹窗通知用户是否同意迁移。

示例性的，如图8C中的(a)所示，若手机B在显示直播界面811时，接收到手机A发送的认证请求消息，手机B可以显示弹框812，弹框812中包括提示信息“HUAWEI MATE30请求将直播界面迁移到本机，是否同意”，响应于用户点击下拉按钮813的操作，如图8C中的(b)所示，弹框812可以显示更多内容，例如显示不同意按钮814和同意按钮815a。

可选的，响应于用户点击同意按钮815a的操作，如图8C中的(c)所示，手机可以显示弹框815b，弹框815b中可以包括仅本次同意按钮815c和一直同意(以后不再提示)按钮815d。应该理解的是，响应于用户点击仅本次同意按钮815c的操作，执行下述步骤917-步骤932后，手机A可以向手机B迁移一次直播界面(即FA1)。下次从手机A的直播应用向手机B的直播应用迁移FA时，需要重新认证，例如可以重新执行步骤901-步骤932。响应于用户点击一直同意按钮815d的操作，执行下述步骤917-步骤932后，手机A的直播应用可以一直向手机B的直播应用迁移FA，无需再次认证(例如无需重新执行步骤901-步骤932)。

917、可选的，手机B接收用户同意迁移的操作。

示例性的，如图8C中的(b)所示，手机B可以接收用户点击同意按钮815a的操作。

若用户同意(例如，若用户点击同意按钮815a)，手机B的DM可以通过通信模块将用户同意的信息返回给手机A的DM，手机A可以提示用户主动扫描对端(手机B)显示的二维码(二维码图片)。

另外，若用户不同意(例如，若用户点击不同意按钮814)，手机B的DM可以通过通信模块将用户不同意的信息返回给手机A的DM，手机A可以显示如图5E中的(c)所示的提示信息，迁移失败。

应该理解的是，在手机A与手机B进行设备级认证时，步骤916和步骤917可以是可选的。例如，若手机A与手机B登录了同一个账号，或者设置了亲情号码等服务，手机B可以不向用户请求是否同意迁移，直接执行步骤918A及其后续的必要步骤。

步骤916和步骤917是手机B提示用户是否同意迁移的一种实现方式，手机B还可以通过其他方式提示用户，例如通过后台系统通知消息通知，本申请不做限定。

918A、手机B的DM判断手机B是否建立过与手机A的直播应用相关的群组。

手机B的DM可以从手机B的HiChain中查询手机B是否建立过与手机A相关的私有群组。相关描述可以参考步骤718A，在此不做赘述。

918B、如果手机B未建立过与手机A的直播应用相关的群组，手机B的DM向手机B的安全管理模块请求创建群组。

手机B的安全模块可以创建一个关于手机A的直播应用的群组(该群组的群组成员可以包括手机A的直播应用和手机B的直播应用)。进一步可以设置群组属性为私有，即特定应用(直播应用)才适用。

可选的，手机B可以将其创建的关于手机A的直播应用的群组的群组ID发送给手机A。手机A可以根据群组ID加入手机B创建的群组。可选的，手机B还可以将手机B的设备ID发送给手机A。手机B的设备ID可以用于手机A与手机B进行通信时使用，手机B的设备ID可以包括网络ID(netId)和设备IP(deviceIP)。

918C、手机B的安全管理模块向手机B的DM发送群组创建成功通知。

应该理解的是，步骤918B和步骤918C是一种示意的创建群组的方式，本申请不限定其他创建群组的方式，例如，手机B的DM可以直接创建群组。

919、手机B的DM向手机B的鸿蒙标签管理模块请求标签。

手机B的鸿蒙标签管理模块可以生成标签，标签中包括认证校验信息，认证校验信息可以包括从手机A接收的token以及手机B的会话标识等信息。手机B的会话标识中包括手机B的设备连接信息。例如，手机B的会话标识包括手机B的Wi-Fi地址(例如，IP地址和端口(Port)号)或者蓝牙地址。认证校验信息还可以包括群组对应的PIN。

920、手机B的鸿蒙标签管理模块向手机B的二维码识别模块请求认证校验信息的二维码图片。

手机B的二维码识别模块可以根据认证校验信息组装二维码图片。

921、手机B的二维码识别模块向手机B的鸿蒙标签管理模块返回二维码图片。

922、手机B的鸿蒙标签管理模块向手机B的DM返回二维码图片。

923a、可选的，手机B的DM向手机B的通信模块发送二维码图片。

在一种可能的设计中，手机B的DM可以将手机B的二维码图片发送给手机A，以便手机A对该二维码图片进行内部扫描，即在步骤923a之后，可以执行步骤923b-步骤925。在另一种可能的设计中，手机B可以将手机B的二维码图片显示在手机B的显示界面(如图8D所示的显示界面)，以便手机A直接扫描，从而使得手机A中的二维码识别模块可以直接获取手机B生成的二维码图片，从而跳过步骤923b-步骤925。上述两种设计均可以实现本方案的技术效果，本申请不对此进行限定。

923b、可选的，手机B的通信模块向手机A的通信模块发送二维码图片。

如图9C所示，上述方法还包括：

924、可选的，手机A的通信模块向手机A的DM发送二维码图片。

925、可选的，手机A的DM向手机A的二维码识别模块发送二维码图片。

926、手机A的二维码识别模块扫描二维码，将识别到的信息发送给手机A的鸿蒙标签管理模块。

927、手机A的鸿蒙标签管理模块解析二维码识别模块发送的信息，得到解析结果。

其中，解析结果可以包括手机B的token、PIN和手机B的会话标识等信息。

928、手机A的鸿蒙标签管理模块向手机A的DM发送解析结果。

可以理解的是，步骤924-步骤928是手机A处理二维码图片的一种示意的实现方式，手机A还可以通过其他方式处理二维码图片，本申请不做限定。例如，手机A的DM可以集成二维码图片处理功能，这样手机A的DM可以直接扫描和解析二维码图，以得到token、PIN和手机B的会话标识等信息。

929、手机A的DM校验token。

若从手机B接收到的token与认证请求消息中携带的token相同，执行步骤930。

930、手机A的DM回调认证成功。

应该理解的是，在手机A与手机B进行设备级认证时，步骤929和步骤930是可选的。若执行步骤929和步骤930，即若手机A的DM校验token，可以更好地保证手机A和手机B通信的安全性。

931、手机A的直播应用加入手机B创建的私有群组。

手机A的DM根据会话标识索引本端保存的对端设备(即手机B)的Wi-Fi地址或者蓝牙地址，向手机A的安全模块申请加入手机B创建的私有群组。

手机A的安全模块利用Wi-Fi地址或蓝牙地址创建底层通信通道，并向手机B发送加入群组请求，该加入群组请求中包括解析得到的PIN和群组ID。手机B接收到加入群组请求，校验PIN，认证通过(即该PIN与二维码图片中的PIN相同)后，两个设备中的直播应用加入同一个群组(该群组的群组成员可以包括手机A的直播应用和手机B的直播应用，该群组的属性为私有)，完成认证。

在一种可能的实现方式中，当手机B接收到加入群组请求并认证通过后，会向手机A发送一个响应消息，该响应消息指示手机A的直播应用已加入手机B创建的私有群组。

932、手机A的安全管理模块通知直播应用认证成功。

这样，手机A的直播应用和手机B的直播应用之间完成了应用级认证，手机A和手机B间的直播应用可以实现互通。

933、手机A的直播应用请求手机A的DEF迁移FA1。

其中，FA1可以实现直播应用中的全部或者部分功能，它由一个多个用户界面组成。

934、手机A的DEF向手机B的DMS发送FA1的业务信息。

FA1的业务信息可以包括直播的视频流、音频流、弹幕信息等。

935、手机B的DMS请求手机B的DEF接续FA1。

其中，手机B的DEF接续FA1是指手机B根据接收到的业务信息处理FA1并显示。其中，手机B上的FA1的显示内容可以与手机A上的FA1的显示内容保持同步，也可以与手机A上FA1的显示内容存在着格式或者部分内容上的差异，本申请不对此进行限定。

936、手机B的DEF拉起展示FA1。

其中，手机B的DEF拉起FA1是指手机B运行和显示FA1。

若手机B当前处于直播画面(即运行FA2)，手机B的DEF可以对手机B的FA2进行检测，若FA2具有展示FA1的能力(即FA2支持展示多个FA)，DEF可以在FA2上拉起展示直播FA1，即将FA1界面展示在FA2界面上。例如，如图8E所示，手机B可以在直播界面811上显示手机A发送的直播界面819。这样，用户可以在手机B上同时观看到手机B的直播画面和手机A的直播画面，达到跨设备展示一个或多个FA的体验，省去用户来回切换终端的繁琐，简化了用户操作，可以提高用户体验。

若手机B当前处于直播画面(即运行FA2)，但FA2不具有展示FA1的能力，则FA1迁移失败，但是手机A还可以继续分享直播应用的其他FA(例如，直播购物车FA3)，无需再次建立连接。

若手机B当前处于桌面界面，则可以在桌面上预览、控制手机A的FA1。

应该理解的是，如果存在手机C迁移手机C上的FA(例如，FA4)给手机B，且手机B当前处于FA2显示界面，若FA2具有展示多个FA的能力，手机B可以同时展示3个FA(FA1、FA2和FA3)，依次类推。

本申请实施例主要应用于跨设备在直播应用之间分享FA的场景，即通过多设备的FA分享，使得某一个设备可以同时展示多个FA的场景，这样，可以自由进行双视角双画面直播，可用于测评直播(开箱特写+主播)、运动导播(运动员视角+解说)，教育直播(书本特写+老师)，电商直播(商品细节+秀导)等场景，能够提升用户使用体验和产品竞争力。

在一些实施例中，若手机A和手机B中的一个登录了账号(例如，华为账号)，另一个没有登录账号，手机A和手机B可以执行上述步骤901-步骤936。以便在手机A和手机B之间进行FA迁移时进行验证(即进行设备级认证)，以保证设备间的数据(例如，FA1)的安全。

在一些实施例中，若手机A和手机B都没有登录账号(例如，华为账号)，手机A和手机B可以执行上述步骤901-步骤936。以便在手机A和手机B之间进行FA迁移时进行验证，以保证设备间的数据的安全。

在一些实施例中，若手机A和手机B登录了同一个账号(例如，华为账号)，手机A和手机B可以执行上述步骤901-步骤936。以便在手机A和手机B之间进行FA迁移时进行验证，进一步保证设备间的数据的安全。

需要说明的是，上述步骤901-步骤936中的部分步骤可以是可选的，即不是应用级认证方案的必要技术特征。例如，步骤903和步骤904可以是可选的步骤，即可以不查询已认证设备，直接查看周边的设备。又例如，步骤911和步骤913可以是可选的步骤，即可以不发送创建成功通知。又例如，步骤916和步骤917可以是可选的步骤，即可以不经过用户同意，直接迁移。又例如，步骤923b-步骤925可以是可选的步骤，此时手机A可以直接获取手机B生成的二维码图片(例如，通过扫描手机B显示的二维码图片)。

下面结合具体的场景，以拍照应用为例，对本申请实施例提供的应用级认证的UI界面进行介绍。

外出旅游时，一行人需要拍团队照，往往需要找一个路人或通过手表等外设控制拍照按钮来拍照。但是通过找路人或通过手表等外设来拍照的方式因为不清楚拍照时的状况往往很难拍出合适的照片。本申请提供一种方法，基于跨设备FA分享技术技术，在两个设备建立连接，将一个设备(例如，手机A)作为拍照手机，并将远端设备的拍照FA迁移至另一个设备(例如，手机B)，这样，用户可以通过手持手机B观察手机A的拍照画面并控制拍照，有助于用户拍出更满意的照片，可以提高用户体验。

如图10A所示，用户采用手机A拍照时，手机A显示拍照界面1001，拍照界面包括预览框和菜单区域。响应于用户A点击菜单区域的迁移按钮1002的操作，手机A可以将手机A的拍照界面(手机A的拍照界面可以看做一个FA，例如，FA5)发送给手机B，如图10B所示，手机B可以显示手机A的拍照界面，并且手机B可以控制手机A的拍照界面。

下面以拍照应用为例，对本申请实施例提供的方法的具体实现方式进行说明。本申请实施例提供的方法可以应用于两个近场设备，例如手机A和手机B，手机A和手机B为异账号设备。如图11所示，包括：

1101、用户在手机A的拍照应用中点击“迁移”按钮。

示例性的，如图10A所示，用户A可以在拍照界面1001中点击迁移按钮1002。

1102、手机A的拍照应用向手机A的DM发起迁移请求。

迁移请求中携带的信息包括发起端包名(本端拍照应用包名)，接续端包名(对端拍照应用包名)，手机A的名称。

步骤1103-步骤1132可以参考步骤903-步骤932的相关描述，在此不做赘述。其中，步骤903-932中的部分步骤可以是可选的。

1133、手机A的拍照应用请求手机A的DEF迁移FA5。

1134、手机A的DEF向手机B的DMS发送FA5的相关信息。

FA5的相关信息可以包括拍摄预览画面和拍摄界面的菜单栏信息。

1135、手机B的DMS请求手机B的DEF接续FA5。

手机B的DEF接续FA5是指手机B根据接收到的业务信息处理FA5并显示。

1136、手机B的DEF拉起展示FA5。

如图10B所示，手机B可以显示并控制手机A的拍照界面(FA5)。本申请实施例通过跨设备FA分享技术使得两个设备建立连接，将手机A的FA5分享至手机B上，使得在手机B上可以预览拍摄界面，还可以控制手机A的拍照功能，有助于用户拍出更满意的照片，可以提高用户体验。

下面结合具体的场景，以K歌应用为例，对本申请实施例提供的应用级认证的UI界面进行介绍。

随着互联网的迅速发展，移动式的K歌越来越受到用户的欢迎。例如，用户打开K歌应用授权登录后，可以创建对应的歌房，并可通过分享歌房链接或者邀请码的方式邀请其他用户进入歌房，其他用户可以通过直接点击链接或者输入邀请码进入同一歌房，进行点歌、演唱等操作。但是，上述分享过程存在较多问题：1)面对面地向朋友分享本端创建的歌房，需要通过微信

等转发链接，分享步骤较多；2)对端用户收到歌房链接并点击进入歌房时，若对端设备未安装K歌应用，需要跳转应用市场进行K歌应用的安装，之后重新点击链接进入歌房，用户体验不佳；3)歌房的分享以及进入强依赖设备上微信

K歌等应用，无法实现即时使用近场体验更佳的设备(如电视)。

本申请针对K歌场景，提供了一种基于FA共享的多设备协同控制方案，支持同网络(例如，同一个Wi-Fi网络)下跨设备应用级互助分享。例如，可以将本机(例如，手机A)的K歌服务无缝流转至或其他终端设备(例如，电视、音箱)；同时无需用户账号授权登录，也不要求多个终端设备使用同一个系统。这样，可以发挥电视、音箱等设备的影音播放体验优势，发挥手机等设备交互便捷、拾音方便的优势，操作步骤简单快捷，极大地提升用户体验。

如图12A中的(a)所示，用户在手机A打开K歌应用后，手机A可以显示K歌界面1201，响应于用户点击歌曲“红豆”对应的K歌按钮1202的操作，如图12A中的(b)所示，手机A可以显示红豆的K歌界面1203，响应于用户点击迁移按钮1204(迁移按钮1204用于将手机A的K歌界面迁移(发送)至其他设备(例如，手机B))的操作，如图12B中的(a)所示，手机可以弹出弹框1205，弹框1205中可以包括附近的设备，附近的设备包括已认证设备(卧室电视，monica’s Mate pad等)和未认证设备(房间电视，Brian’s Mate pad和Mate book X pro等)。响应于用户点击房间电视(未认证过的设备)对应的控件1206的操作，手机A可以向手机B发送认证请求消息。并且，如图12B中的(b)所示，在房间电视的下方可以显示提示信息1207“等待对端确认”。如图12C所示，电视可以显示弹框1210，弹框1210中包括提示信息“HUAWEIMATE30(手机A)请求将K歌服务迁移到本机，是否同意”，弹框1210中还可以包括不同意按钮1212和同意按钮1213。响应于用户点击同意按钮1213的操作，如图12D所示，电视可以显示弹框1214，弹框1214中可以包括电视生成的二维码图片，还可以包括提示信息1215“扫一扫认证，允许HUAWEI MATE30扫一扫认证”。此时手机A的用户可以扫一扫电视展示的二维码图片，而后，电视可以从手机A接收K歌界面(K歌界面可以视为一个FA，例如FA6)，如图12E所示，电视可以展示K歌界面1217。或者，响应于用户点击同意按钮815的操作，电视可以从手机A接收K歌界面(FA6)，如图12E所示，电视可以展示K歌界面1217。进一步的，如图12F所示，手机A可以重新编排UI，作为点歌控制台，用户在手机A上进行点歌、切歌等操作以及歌单信息会通过通信数据通道同步发送给电视，可以控制电视侧音乐的播放。

下面以K歌应用为例，对本申请实施例提供的方法的具体实现方式进行说明。本申请实施例提供的方法可以应用于处于同一网络下的两个近场设备，例如手机A和电视，手机A可以为安卓系统或双框架系统，电视可以为鸿蒙系统，手机A和电视为异账号设备。如图13所示，包括：

1301、用户在手机A的K歌应用中点击“迁移”按钮。

1302、手机A的K歌应用向手机A的DM发起迁移请求。

迁移请求中携带的信息包括发起端包名(本端K歌应用包名)，接续端包名(对端K歌应用包名)，手机A的名称。

步骤1303-步骤1332可以参考步骤903-步骤932的相关描述，在此不做赘述。其中，步骤903-932中的部分步骤可以是可选的。

1333、手机A的K歌应用请求手机A的DEF迁移FA6。

1334、手机A的DEF向电视的DMS发送FA6的相关信息。

FA6的相关信息可以包括K歌的歌曲信息，歌曲信息包括歌名(例如，红豆)、歌词、音频信息和视频信息中的至少一种。

1335、电视的DMS请求电视的DEF接续FA6。

1336、电视的DEF拉起展示FA6。

若电视安装K歌应用，电视的DEF可以电视的K歌应用和账号是否登录进行检测，提示用户登录K歌应用，以便K歌应用展示手机A发送的FA6。

若电视未安装K歌应用，电视的DEF可以拉起FA6，即提供展示FA6的能力，无需预装K歌应用，可以达到即时使用K歌服务的效果。

本申请实施例针对K歌娱乐场景提供了一种近场应用层数据共享业务，可实现跨设备跨操作系统间FA的一键迁移，不需要依赖任何三方平台，不要求预装K歌应用，可以即时使用K歌服务，快速打造移动式K歌房，能够提升用户体验，操作简单，提升娱乐体验。

下面结合具体的场景，以购物应用为例，对本申请实施例提供的应用级认证的UI界面进行介绍。

随着互联网的迅速发展，尤其是移动互联网的普及，网络购物已经成为大部分人日常生活必不可少的元素。手机、平板作为网络购物中最常用的终端设备，如果能在用户的购物体验方面有较好的提升，无疑会大大增强终端设备的市场竞争力。以使用手机购物为例，在各种购物节中，商家会推出很多满减的优惠活动，用户为了追求更实惠的价格，往往会找身边的朋友、家人一起拼单来购买某些商品，从而达到商家的满减额度。在这个过程中，存在以下几个痛点：1)面对面地向朋友分享某件商品，也需要通过微信来转发，分享步骤较多；2)为了参加优惠，用户会在商品选购界面和购物车之间频繁切换，操作琐碎繁杂；3)当多人一起拼单购买某个商家的商品时，分享商品，添加购物车和切换界面等操作将会更加频繁，完成付款后还需要附带转账操作，极为不便。针对这类问题，部分厂商提出面对面拼单的解决方案，可以通过微信

扫码将想要拼单的商品分享给身边的其他用户，实现面对面快捷拼单操作。但是该解决方案存在一些弊端：一方面商家平台和使用场景有着较大的限制，另一方面从用户A付款到分享二维码给用户B，用户B再打开微信扫码，浏览，购买该商品，分享过程依旧依赖微信平台，步骤较多。

本申请针对网络购物场景，提供了一种基于近场FA共享的应用层数据共享业务，支持同网络(例如，同一个Wi-Fi网络)下多个终端设备之间一键同步购物车信息，可以将一个终端设备的购物车(购物车可以视为一个FA，例如，FA7)迁移到另一个终端设备中，两个设备的购物车的商品可以统一结算享受满减优惠，再分开付款省去相互转账的烦恼，操作步骤简单快捷，可以极大地提升拼单购物的用户体验。同时由于近场FA共享能力是系统服务提供的基础能力，不需要同操作系统，也不需要登录同一个设备账号(例如，华为账号)，甚至不需要设备上安装购物应用，通用性高，能被各个电商平台所使用，且适配成本小，能让更多的用户享受到更加便捷的网络购物体验。

示例性的，如图14A所示，用户在手机A打开购物应用后，可以进入购物车界面1401，响应于用户在购物车界面1401点击迁移按钮1402(迁移按钮1402用于将手机A的购物车迁移(发送)至其他设备(例如，手机B))的操作，如图14B中的(a)所示，手机可以弹出弹框1403，弹框1403中可以包括附近的设备，附近的设备包括已认证设备(卧室电视，monica’sMate pad等)和未认证设备(房间电视，HUAWEI P20和Mate book X pro等)。响应于用户点击HUAWEI P20(未认证过的设备)对应的控件1404的操作，手机A可以向手机B发送认证请求消息。并且，如图14B中的(b)所示，在HUAWEI P20的下方可以显示提示信息1405“等待对端确认”。如图14C所示，若手机B(HUAWEI P20)在显示桌面时接收到手机A发送的认证请求消息，手机B可以显示弹框1410，弹框1410中包括提示信息“HUAWEI MATE30(手机A)请求将购物车迁移至本机，是否同意”，弹框1410可以包括不同意按钮1412和同意按钮1413。响应于用户点击同意按钮1413的操作，如图14D所示，手机B可以显示弹框1415，弹框1415中可以包括手机B生成的二维码图片，还可以包括提示信息1416“扫一扫绑定，允许HUAWEI MATE30扫一扫认证”。此时手机A的用户可以扫一扫手机B展示的二维码图片，而后，手机B可以从手机A接收购物车(FA6)，或者，响应于用户点击同意按钮1413的操作，手机B可以从手机A接收购物车(FA6)。如图14E所示，手机B可以在购物车界面1417显示共享购物车，共享购物车中既包括“我”添加的商品，也包括用户A(手机A的用户)添加的商品。另外，手机B也可以将自身的购物车(例如，FA7)迁移至手机A，这样，如图14F所示，手机A可以在购物车界面1407显示共享购物车，共享购物车中既包括“我”添加的商品，也包括用户B(手机B的用户)添加的商品。这样，用户可以一键实现拼单购物，不需要依赖任何三方平台分享，省去了相互分享商品，相互转账的繁冗步骤，大大提升购物体验。

下面以购物应用为例，对本申请实施例提供的方法的具体实现方式进行说明。本申请实施例提供的方法可以应用于两个近场设备，例如手机A和手机B，手机A和手机B为异账号设备。如图15所示，包括：

1501、用户在手机A的购物应用中点击“迁移”按钮。

如图14A所示，用户在手机A打开购物应用后，选择商品添加至购物车，然后进入购物车界面1401，用户可以在购物车界面1401点击迁移按钮1402，迁移按钮1402用于将手机A的购物车迁移(发送)至其他设备(例如，手机B)。

1502、购物应用向手机A的DM发起迁移请求(分享请求)。

迁移请求中携带的信息包括发起端包名(本端购物应用包名)，接续端包名(对端购物应用包名)，手机A的名称。发起端包名例如com.huawei.vmall，接续端包名例如com.huawei.vmall。

步骤1503-步骤1532可以参考步骤903-步骤932的相关描述，在此不做赘述。其中，步骤903-932中的部分步骤可以是可选的。

1533、手机A的购物应用请求手机A的DEF迁移FA7。

1534、手机A的DEF向手机B的DMS发送FA7的相关信息。

FA7的相关信息包括购物车中的商品信息，商品信息包括商品名、商品链接和商品价格等信息中的至少一种。

1535、手机B的DMS请求手机B的DEF接续FA7。

1536、手机B的DEF拉起展示FA7。

手机B的DEF拉起FA7，如图14E所示，手机B可以在购物车界面1417显示共享购物车，其中既包含了自己购物车中的一件商品，也包含了用户A选择的三件商品。此时用户B可以直观地看到拼单购买的所有商品，选中购物车的部分或全部商品后，用户可以查看金额是否满足满减活动，实现了快捷的拼单功能。

另外，共享购物车中的商品信息可以实时更新，例如发起迁移的设备(例如，手机A)购物车中有新增商品，目的设备(例如，手机B)的共享购物车也可以即使刷新。

进一步的，用户B点击“结算”按钮时，手机B可以向用户A发起付款请求并携带付款相关信息，付款相关信息可以包括收款平台和付款金额等。其中，付款金额可以为：各自购买的商品总额－(各自总额/共享购物车总金额)*优惠值。待付款完成后，共享购物车清空，一次拼单购物流程结束。

基于本申请实施例提供的方法，可以将一个终端设备的购物车(购物车可以视为一个FA，例如，FA7)迁移到另一个终端设备中，两个设备的购物车的商品可以统一结算享受满减优惠，再分开付款省去相互转账的烦恼，操作步骤简单快捷，可以极大地提升拼单购物的用户体验。

在又一些实施例中，在家庭环境下，一名用户持有一部手机以及一部电视，正在参与购物节满400减100的活动。传统的购物场景下，该用户在用手机挑选商品的过程中会频繁地切换商品详情页面与购物车页面，以查看或修改购物车内容。基于本申请实施例提供的方法，用户可以将购物车迁移到电视上，在手机上浏览和选择商品，在电视上可以随时观看购物车的内容，省去了手机反复切换页面的繁杂操作，可以提高用户体验。

在又一些实施例中，用户在两个手机(手机A和手机C)上分别选中了一些商品加入了购物车，用户可以同时把手机A和手机C的购物车都迁移到电视B上。当手机A和手机C分别与电视B认证完成后，手机A上的群组成员可以包括(A的购物应用，B的购物应用)；手机C上的群组成员可以包括(C的购物应用，B的购物应用)；电视B上的群组成员包括(A的购物应用，B的购物应用和C的购物应用)，电视的群组包括三个成员。即电视的购物应用分别与手机A的购物应用和手机C的购物应用进行了应用级认证，后续可以分别与手机A和手机C的购物应用进行互通。

应该理解的是，基于近场FA共享能力来实现的购物车FA迁移场景，其主要适用于组网环境下，如家庭环境和工作环境。对于不能近场组网(短距组网)的场景，该方案也有借鉴价值，例如可以利用互联网实现购物车内容的共享和实时同步。或者，电商平台可以将互联网环境下的购物车集成到自己的购物应用中，通过自身的云服务和账号来实现共享。

下面结合具体的场景，以邮件应用为例，对本申请实施例提供的应用级认证的UI界面进行介绍。

当前，办公软件如邮箱的使用场景正在发生一些变化，除了传统的办公室和家庭场景外，外地出差/交通工具/等候/户外走动都成为了办公人员的使用场景。已有厂商在各个移动平台上提供邮箱客户端，使得用户在多种设备上都能访问邮箱，但是当用户在移动办公与非移动办公状态切换时，无法无缝切换，操作不能连续进行，用户体验不好。例如，在智能手表上收到邮件通知时，想要在手机或者Pad上回复时，还需要打开手机/Pad，登录邮箱，查找到邮件，然后回复，操作繁琐，用户体验较差。目前，苹果公司提出的接力(handoff)技术可以让用户从一台苹果设备(例如，Mac、iPhone、iPad或Apple Watch等)切换到附近另一台苹果设备上继续工作，任务进程不丢失。但这要求邮箱接力的设备必须登录同一个AppleId，提前安装相同的邮箱客户端，且登录邮箱账号；并且该技术无法针对推送设备进行选择，比如在会议室需要将某一封邮件推送到电视上展示，由于两个设备未登录同一个AppleId，接力无法实现。

本申请针对商务人员移动办公和非移动办公切换场景，提供了一种基于近场跨设备FA迁移的应用接续业务，支持多个终端设备之间一键迁移邮件。例如，手表可以一键拉起手机侧邮件查看界面，在手机侧一步直达邮件正文。又例如，对于手机侧正在编辑的邮件草稿，本申请同样支持一键将其无缝转移到其他设备(例如，其他手机、PAD或电视)中继续进行，提供极致的多设备邮件协同体验。本申请不需要同系统，也不要求设备登录同一个账号，甚至不需要两端设备都安装邮箱应用，适用范围广。

示例性的，用户在手机A收到一封邮件并打开后，如图16A所示，手机A可以显示邮件界面1601(邮件界面1601可以视为一个FA，例如，FA8)，响应于用户在邮件界面1601点击迁移按钮1602(迁移按钮用于将手机A的邮件界面迁移(发送)至其他设备(例如，电视))的操作，如图16B中的(a)所示，手机A可以弹出弹框1603，弹框1603中可以包括附近的设备，附近的设备包括已认证设备(monica’s Mate pad等)和未认证设备(电视，HUAWEI P20和Matebook X pro等)。响应于用户点击电视(未认证过的设备)对应的控件1604的操作，手机A可以向电视发送认证请求消息。并且，如图16B中的(b)所示，在电视的下方可以显示提示信息1605“等待对端确认”。如图16C所示，电视可以显示弹框1610，弹框1610中包括提示信息“HUAWEI MATE30(手机A)请求将邮件迁移到本机，是否同意”，弹框1610中还可以包括不同意按钮1614和同意按钮1615。响应于用户点击同意按钮1613的操作，如图16D所示，电视可以显示弹框1614，弹框1614中可以包括电视生成的二维码图片，还可以包括提示信息1615“扫一扫认证，允许HUAWEI MATE30扫一扫认证”。此时手机A的用户可以扫一扫电视展示的二维码图片，而后，电视可以从手机A接收邮件界面(FA8)，如图16E所示，电视可以显示邮件界面1616。或者，响应于用户点击同意按钮1613的操作，电视可以从手机A接收邮件界面(FA8)，如图16E所示，电视可以显示邮件界面1616。

下面以邮件应用为例，对本申请实施例提供的方法的具体实现方式进行说明。本申请实施例提供的方法可以应用于两个近场设备，例如手机A和PC，手机A可以是安卓系统，PC可以是鸿蒙系统，手机A和PC为异账号设备。如图17A所示，包括：

1701、用户在手机A的邮件应用中点击“迁移”按钮。

用户在手机上打开一封邮件编辑，点击编辑界面的“迁移”按钮。

1702、手机A的邮件应用向手机A的DM发起迁移请求。

迁移请求中携带的信息包括发起端包名(本端邮件应用包名)，接续端包名(对端邮件应用包名)，手机A的名称。

步骤1703-步骤1732可以参考步骤903-步骤932的相关描述，在此不做赘述。其中，步骤903-932中的部分步骤可以是可选的。

1733、手机A的邮件应用请求手机A的DEF迁移FA8。

邮件应用可以携带本设备和目标设备参数(例如，本设备和目标设备的标识)向手机A的DEF请求接续FA8。

1734、手机A的DEF向电视的DMS发送FA8的相关信息。

FA8的相关信息可以包括邮件内容信息，邮件内容信息可以包括主题，正文，附件等信息。

1735、电视的DMS请求电视的DEF接续业务。

1736、电视的DEF拉起展示FA8。

若电视安装有邮箱客户端，电视的DEF可以对邮箱客户端和账号是否登录进行检测，提示用户登录邮箱账号，从而邮箱应用可以拉起展示FA8，即显示手机A迁移过来的邮件界面。

若电视未安装邮箱客户端，电视的DEF可以拉起展示FA8，即将FA8进行编码重排显示，这样未登录/未安装邮箱客户端的设备也可以展示邮件内容，且可以避免邮箱账号等隐私信息泄露。另外，若电视的DEF不支持展示FA8，可以从应用市场下载安装能够展示FA8的FA(该FA可以是第三方应用厂商开发的)。

进一步的，用户可以在电视上对邮件进行编辑、回复等操作，编辑、回复的邮件内容可以通过数据通信通道回传到手机A，并依据手机A的账号信息将邮件发送出去。这样，即使电视未安装邮箱客户端，或者未登录邮箱账号，也可实现一键迁移，提升用户体验，提高办公效率。迁移设备可以只作为展示和编辑使用，最终邮件收发均由迁移发起端执行，迁移的设备只能查看发起端主动推送的邮件，流程结束后内容主动销毁，做到真正的邮件随人走，无缝切换。

本申请可以使邮件在多设备间流转，不要求登录同一设备账号，也不要求所有设备都安装邮箱客户端和登录邮箱账号，大大拓宽可用设备范围。

另外，若两个设备间已完成组网和认证，直接点击迁移按钮即可完成迁移，更加方便快捷。例如，假设手表、手机和PC之间已完成组网和认证，如图17B所示，用户的手表接收邮件通知后，可以显示邮件通知界面1701，提示用户有一封信邮件，响应于用户点击查看按钮1702的操作，如图17C所示，手表可以直接拉起手机侧邮件查看界面1704(手表可以向手机发送邮件查看请求，手机可以直接显示邮件查看界面1704)，一步直达邮件正文。用户在手机上编辑回复邮件的过程中，如果需要插入一份文档，但是文档保存在PC中，用户可以在手机上点击迁移按钮1705将邮件迁移到PC，如图17D所示，PC可以显示邮件编辑界面1706，用户在邮件编辑界面1706插入附件后可以点击迁移按钮1707将携带附件的邮件重新迁移到手机。这样，手表、手机和PC之间可以方便快捷地协同工作，用户体验较高。

本申请基于近场跨设备FA迁移技术，实现邮件在移动办公和非移动办公间一键迁移，无缝流转，大大提升多设备协同办公体验。多设备迁移邮件脱离用户账号/邮箱客户端/邮箱账号的限制，可覆盖同一组网下的多种设备，大大拓宽了邮件迁移的使用场景。

上述实施例是以接收方(被动迁移设备，例如手机B，电视等)生成二维码信息，发起方(主动迁移设备，例如手机A)解析手机B的二维码信息加入手机B创建的群组进行认证的。

在另一些实施例中，也可以由发起方(主动迁移设备，例如手机A)生成二维码信息，接收方(被动迁移设备，例如手机B，电视等)根据手机A的二维码信息进行认证。

示例性的，如图18A所示，用户A可以在电视的K歌界面1800选中迁移选项1801(迁移选项1801用于将电视的K歌界面迁移(发送)至其他设备(例如，手机B))。可选的，用户A可以采用控制设备(例如，遥控器，手机等)选中“迁移”选项。或者，若电视是触控设备，用户A可以直接点击“迁移”选项以选中“迁移”选项。如图18B所示，电视可以弹出弹框1802，弹框1802中可以包括电视生成的二维码图片，还可以包括提示信息1803“扫一扫认证，允许其他设备扫一扫加入我的歌房”。用户B可以采用手机B扫描电视显示的二维码图片(手机B可以采用第三方应用(例如，K歌应用等)提供的扫描入口，或者可以采用系统自带的扫描入口)，之后，如图18C中的(a)所示，手机B可以显示K歌界面1804，用户A的头像1805(电视登录的K歌应用的账号的头像，或者电视登录的设备账号(例如华为账号)的头像)可以显示在歌词底层，表示当前用户A正在演唱歌曲。响应于用户点击点歌按钮1806的操作，如图18C中的(b)所示，手机B可以显示弹框1807，响应于用户点击合唱按钮1808的操作，如图18D所示，用户A的头像1811(电视登录的K歌应用的账号的头像，或者电视登录的设备账号(例如华为账号)的头像)和用户B的头像1810(手机B登录的K歌应用的账号的头像，或者手机B登录的设备账号(例如，华为账号)的头像)，表示用户B与用户A合唱同一首歌曲。

下面以K歌应用为例，对本申请实施例提供的应用级认证方法的具体实现方式进行说明。本申请实施例提供的方法可以应用于两个近场设备，例如电视和手机B，电视和手机B为异账号设备(例如，不是同一个华为账号)，且电视和手机B都打开了K歌应用。如图19所示，包括：

1901、用户在电视上的K歌界面选中“迁移”选项。

例如，如图18A所示，用户可以在电视的K歌界面选中迁移选项1801。(迁移选项1801用于将手机A的一系列K歌界面(例如，该一系列K歌界面可以看做FA9)迁移(发送)至其他设备(例如，手机B))。其中，迁移选项也可以称为分享选项、发送选项等，本申请不做限定。

可选的，用户可以采用控制设备(例如，遥控器，手机等)选中“迁移”选项。或者，若电视是触控设备，用户可以直接点击“迁移”选项以选中“迁移”选项。

可选的，用户可以在选中迁移选项1801后进一步选择待迁移的设备，例如可以选中手机B。

1902、电视的二维码识别模块向电视的鸿蒙标签管理模块发起生成二维码请求。

示例性的，生成二维码请求的入参包含一个Bundle对象以及一个异步回调。其中，Bundle对象中包含K歌业务所需的源包名(本端K歌应用包名)和目的包名(对端K歌应用包名或者待迁移的FA的包名)。异步回调包含创建二维码的结果，创建成功可以获取二维码字段，创建失败获取错误码。

1903、电视的鸿蒙标签管理模块向电视的DM请求电视的设备信息。

电视的设备信息可以包括电视的名称、网络ID(netId)和设备IP(deviceIP)等。

Bundle对象将鸿蒙标签管理模块获取的设备信息保存到设备管理，用于创建群组及后续通过通道将客户端应用包名等信息传到对端设备。

1904、电视的DM生成PIN。

电视的DM可以生成随机的PIN。PIN可以是若干位随机数字。可选的，电视的DM还可以生成token，token可以是若干位随机字符串。

1905、可选的，电视的DM调用安全管理模块获取本机设备连接参数。

其中，本机设备连接参数可以包括本机的网络ID(netId)，设备IP(deviceIP)，蓝牙地址(BtMac)，Wi-Fi地址(Wi-FiPort)。其中，netId在本地保存。

1906a、电视的DM调用安全管理模块创建群组。

其中，创建的群组可以是(本机名称(即电视，例如HUAWEI TV)，本机的K歌应用的包名，(对端设备名称可以空缺)，对端K歌应用的包名/待迁移的FA的包名)，该群组当前缺少至少一个成员，允许其他设备作为成员加入。

1906b、可选的，安全管理模块创建群组成功后，向电视的DM发送回调通知。

1907、电视的DM接收到回调通知后，向鸿蒙标签管理模块发送PIN、token和电视的设备信息。

电视的DM在本地保存群组名(groupName)，并将PIN、token和电视的设备信息打包为Bundle类型，通过设备管理回调将其传递给鸿蒙标签管理模块。

1908a、鸿蒙标签管理模块根据PIN、token和电视的设备信息生成二维码图片。

1908b、鸿蒙标签管理模块将二维码信息发送给二维码识别模块。

1908c、二维码识别模块根据二维码信息生成二维码图片并显示该二维码图片。

其中，二维码识别模块可以调用电视的显示功能，从而在电视的显示屏上显示二维码图片。

1909a、手机B打开二维码识别模块扫描电视显示的二维码图片。

1909b、手机B的二维码识别模块识别二维码图片中的二维码信息(也可以称为二维码标签)，拉起鸿蒙标签管理模块并传入二维码信息。

1909c、鸿蒙标签管理模块解析二维码信息，提取二维码信息中存储的字段(字符串)。

1910、手机B的鸿蒙标签管理模块向手机B的DM发送认证请求消息，并注册回调。

认证请求消息包括从二维码信息中解析出的字段。

1911a、手机B的DM对认证请求消息进行处理。

手机B的DM可以对认证请求消息中包括的字段进行拆分，得到deviceIp和Wi-FiPort字段，根据deviceIp和Wi-FiPort调用通信模块接口创建手机B和电视之间的通信通道。

1911b、可选的，手机B的DM通过通信模块向电视的DM发送认证请求消息。

手机B的DM可以将token设置为参数requestId。可以理解的是，手机B的DM还可以通过通信模块向电视的DM发送手机B的设备ID等信息。

1912、可选的，电视的DM校验token。

电视的DM基于参数requestId提取token，将提取的token和本端保存的token进行比较，如果一致则同意两台设备(即电视和手机B)之间创建安全通信通道(安全通信通道例如可以是加密保护的通信通道)，并通过该安全通信通道向手机B发送群组信息，该群组信息包括电视的网络ID，电视创建的群组的群组ID(groupId)、群组类型(groupType)和群组名(groupName)等。

1913、手机B的DM接收并保存电视发送的群组信息。

1914、手机B的DM调用安全管理模块获取与对端设备存在可信关系的所有群组信息，然后通过安全管理模块遍历查询电视的K歌应用应用是否有群组的访问权限。

如果没有权限，设备管理通过HiChain加入指定群组，群组加入成功会触发两端设备的onFinish回调，在该方法中调用HiChain写入对端的包名信息，用于后续查询应用级可信关系。如果已有权限则执行步骤1915。

1915、手机B的DMS接收来自电视的DEF的FA9的相关信息。

FA9的相关信息可以包括K歌的歌曲信息，歌曲信息包括歌名(例如，红豆)、歌词、音频信息和视频信息中的至少一种。

可选的，手机B上进行点歌、切歌等操作以及歌单信息会通过安全通信通道同步发送给电视，可以控制电视侧音乐的播放。

在一些实施例中，若电视和手机B中的一个登录了账号(例如，华为账号)，另一个没有登录账号，电视和手机B可以执行上述步骤1901-步骤1915。以便在电视和手机B之间进行FA迁移时进行验证(即进行设备级认证)，以保证设备间的数据的安全。

在一些实施例中，若电视和手机B都没有登录账号(例如，华为账号)，电视和手机B可以执行上述步骤1901-步骤1915。以便在电视和手机B之间进行FA迁移时进行验证，以保证设备间的数据的安全。

在一些实施例中，若电视和手机B登录了同一个账号(例如，华为账号)，电视和手机B可以执行上述步骤1901-步骤1915。以便在电视和手机B之间进行FA迁移时进行验证，进一步保证设备间的数据(例如，FA9的相关信息)的安全。

需要说明的是，上述步骤1901-步骤1915中的部分步骤可以是可选的，即不是设备级认证方案的必要技术特征。例如，步骤1905可以是可选的步骤，例如电视的DM可以从其他模块获取本机设备连接参数。又例如，步骤1906b可以是可选的步骤，即安全管理模块创建群组成功后，可以不向电视的DM发送回调通知。又例如，步骤1911b和步骤1912可以是可选的步骤，即手机B的DM可以不向电视的DM发送token，电视的DM也无需校验token。

当然，手机C(手机C的设备账号和手机B的设备账号不同，例如未登录同一个华为账号)也可以通过扫描二维码的方式加入电视创建的群组(具体过程可以参考步骤1809-步骤1818)。这样，多个设备可以基于二维码扫码的方式快速拉起FA9，无需预装，即时使用服务；且多个设备扫码后可以建立信任圈进行信息交互，例如多个设备间歌单等信息能够实时刷新同步，多个设备(例如，手机B或手机C)可以协同控制主席端(例如，电视)，实现多设备协同控制，实现真正的移动式KTV体验。

在又一些实施例中，发起方(主动迁移设备，例如电视)可以生成二维码图片(例如，执行步骤1901-1908c)，一个或多个接收方(被动迁移设备，例如手机B和手机C)可以根据电视的二维码图片进行认证(例如，执行步骤1909a-步骤1914)，通过认证后，接收方可以将购物车、直播间、邮件等迁移至电视，从而达到在多个设备(例如，电视、手机B和手机C)之间共享购物车、直播间、邮件等信息的效果，多个设备间的购物车商品信息、直播视频流、邮件内容等信息能够实时刷新同步，多个设备(例如，电视、手机B和手机C)可以协同控制主席端(例如，电视)，实现多设备协同控制，实现真正的协同购物、直播或邮件编辑体验。

需要说明的是，对于本申请实施例提供的各个UI界面，例如上文中的图5A-图5F、图6A-图6C、图8A-图8D、图10A-图10B、图12A-图12E、图14A-图14F、图16A-图16E、图18A-图18C等，各个UI界面的界面设计仅是一种示意，不限定UI界面中的各个元素(例如，按钮、图标、文字等)的位置、名称和形状等。例如，图8A中的按钮802(原本位于界面801的左上角)也可以位于界面801的右下角，按钮802上显示的文字也可以是共享、转移等。在一些实施例中，不同UI界面的元素可以重新排列组合到同一个UI界面。例如，图5A中的(a)中的按钮502可以替换为图5A中的(b)中的按钮503和按钮504。本申请实施例不限定UI界面之间的跳转关系。例如，若本申请实施例出现从第一UI界面跳转至第二UI界面的描述，仅是第一界面和第二界面的一种跳转关系示意，不限定有其他的跳转关系。例如，如图5C中的(b)所示，响应于用户点击绑定按钮509的操作，如图5D中的(b)所示，手机可以直接显示扫描界面512。本申请实施例也不限定UI界面之间的跳转方式(例如，若本申请实施例出现点击第一UI界面的第一按钮跳转至第二UI的描述，仅是第一界面和第二界面的一种跳转方式示意，不限定有其他的跳转方式)。例如，如图8A所示，响应于用户特定手势(例如，三指下滑、指关节敲击等)的操作，如图8B中的(a)所示，手机可以显示弹框803。

本申请实施例提供一种功能迁移方法，如图20所示，包括：

2001、第一设备向第二设备发送第一请求。

其中，第一请求携带第一设备的标识、第一应用的标识和第二应用的标识。第一请求可以是上述实施例中的认证请求消息，相关描述在此不做赘述。

在一种可能的实施方式中，响应于用户在第一设备的第一应用的第一操作，显示第一弹框，第一弹框包括与第一设备处于同一个网络中的设备的标识；响应于用户在第一弹框中选中第二设备的第二操作，向第二设备发送第一请求。示例性的，这里的第一弹框可以是如图5C中的(b)所示的弹框508或者如图8B中的(a)所示的弹框803等。

其中，与第一设备处于同一个网络中的设备包括可信设备和不可信设备；其中，可信设备包括与第一设备登录同一个账号的设备、与第一设备进行过设备级认证的设备或者与第一设备的第一应用进行过应用级认证的设备；不可信设备包括未与第一设备登录同一个账号的设备、未与第一设备进行过设备级认证的设备或者未与第一设备的第一应用进行过应用级认证的设备。其中，第一设备可以是上述实施例中的手机A。

2002、第二设备接收来自第一设备的第一请求。

第一设备接收第一请求之后，可以显示第一弹框，第一弹框用于提示用户是否同意将第一设备的第一应用加入第一群组；接收来自用户的同意指令。示例性的，这里的第一弹框可以是如图6A中的(a)所示的弹框531，或者可以是如图8C中的(a)所示的弹框812等。

其中，第二设备可以是上述实施例中的手机B。

2003、第二设备创建第一群组，第一群组的成员包括第二设备的第二应用。

第二设备创建第一群组之前，可以根据第一设备的标识确定第二设备当前没有第二群组，其中，第二群组的成员包括第一设备和第二设备。

第二设备创建第一群组之前，可以根据第一设备的标识、第一应用的标识和第二应用的标识，确定第二设备当前没有第三群组，其中，第三群组的成员包括第一设备的第一应用以及第二设备的第二应用。

2004、第二设备向第一设备发送第一响应。

第一响应可以包括第一群组对应的个人识别码PIN和/或第二设备的通信连接信息。

2005、第一设备从第二设备接收第一响应。

第一响应用于指示第二设备创建的第一群组，第一群组的成员包括第二设备的第二应用。

2006、第一设备向第二设备发送第二请求。

第二请求用于申请将第一设备的第一应用加入第一群组。

在一种可能的实现方式中，第二设备可以显示二维码图片，二维码图片包括第一群组对应的个人识别码PIN和/或第二设备的通信连接信息。第一设备可以扫描第二设备显示的二维码图片，获取第一群组对应的个人识别码PIN和/或第二设备的通信连接信息，第一设备可以根据PIN和/或第二设备的通信连接信息向第二设备发送第二请求。

可选的，第一设备根据PIN和/或第二设备的通信连接信息向第二设备发送第二请求。

2007、第二设备接收来自第一设备的第二请求。

第二设备可以根据第二请求将第一设备的第一应用加入第一群组。

可选的，第二设备可以向第一设备发送第二响应，第一设备可以接收第二响应，其中，第二响应用于指示第一设备的第一应用已加入第一群组。

2008、第一设备将第一应用中的第一功能迁移到第二设备的第二应用，第一功能包括一个或者多个UI。

可选的，第一设备可以创建第二群组，其中，第二群组的成员包括第一设备的第一应用以及第二设备的第二应用。

2009、第二设备接收第一设备迁移的第一应用中的第一功能，其中，第一功能包括一个或者多个UI。

图20的实施例中的第一设备或第二设备可以分别为前述实施例中的手机A和手机B等，图20的实施例中未详述的部分，可以参考前述实施例，在此不做赘述。

本申请实施例提供一种功能迁移方法，如图21所示，包括：

2101、第一设备向第二设备发送第一请求。

第一请求携带第一设备的标识。

2102、第二设备从第一设备接收第一请求。

2103、第二设备向第一设备发送第一响应。

第一响应用于指示第二设备创建的第一群组，第一群组的成员包括第二设备。

2104、第一设备从第二设备接收第一响应。

2105、第一设备向第二设备发送第二请求，第二请求用于申请将第一设备加入第一群组。

2106、第一设备将第一应用中的第一功能迁移至第二设备，第一应用为第一设备中的任一个应用，第一功能包括一个或多个图形用户界面UI。

图21的实施例中的第一设备或第二设备可以分别为前述实施例中的手机A和手机B等，第一请求可以是上述实施例中的认证请求消息等。图21的实施例中未详述的部分，可以参考前述实施例，在此不做赘述。

本申请实施例提供一种功能迁移方法，如图22所示，包括：

2201、第一设备创建第一群组，第一群组的成员包括第一设备的第一应用。

2202、第二设备向第一设备发送第一请求，第一请求用于申请将第二设备的第二应用加入第一设备创建的第一群组，第一群组的成员包括第一设备的第一应用和第二设备的第二应用。

2203、第一设备从第二设备接收第一请求，第一请求用于申请将第二设备的第二应用加入第一群组。

2204、第一设备将第二设备的第二应用加入第一群组。

2205、第一设备将第一应用中的第一功能迁移到第二设备的第二应用，第二功能包括一个或者多个UI。

2206、第二设备从第一设备接收第一应用中的第一功能，其中，第一功能包括一个或者多个UI。

图22的实施例中的第一设备或第二设备可以分别为前述实施例中的手机A和手机B等，第一请求可以是上述实施例中的认证请求消息等。图22的实施例中未详述的部分，可以参考前述实施例，在此不做赘述。

本申请另一些实施例提供了一种第一设备或第二设备，第一设备或第二设备可以是如图3所示的电子设备200。第一设备或第二设备可以包括：通信模块、存储器和一个或多个处理器。该通信模块、存储器与处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。

本申请另一实施例提供一种芯片系统，如图23所示，该芯片系统包括至少一个处理器2301和至少一个接口电路2302。处理器2301和接口电路2302可通过线路互联。例如，接口电路2302可用于从其它装置(例如，电子设备的存储器)接收信号。又例如，接口电路2302可用于向其它装置(例如处理器2301)发送信号。

例如，接口电路2302可读取电子设备中存储器中存储的指令，并将该指令发送给处理器2301。当所述指令被处理器2301执行时，可使得第一设备/第二设备(如图6所示的电子设备230)执行上述各实施例中的各个步骤。

又例如，接口电路2302可读取服务器中存储器中存储的指令，并将该指令发送给处理器2301。当所述指令被处理器2301执行时，可使得服务器执行上述实施例中的各个步骤。

当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种功能迁移方法，其特征在于，应用于第一设备，所述方法包括：

向第二设备发送第一请求，所述第一请求携带所述第一设备的标识、第一应用的标识和第二应用的标识；

从所述第二设备接收第一响应，所述第一响应用于指示所述第二设备创建的第一群组，所述第一群组的成员包括所述第二设备的所述第二应用；

向所述第二设备发送第二请求，所述第二请求用于申请将所述第一设备的所述第一应用加入所述第一群组；

将所述第一应用中的第一功能迁移到所述第二设备的所述第二应用，所述第一功能包括一个或者多个图形用户界面UI。

2.根据权利要求1所述的方法，其特征在于，所述第一响应包括所述第一群组对应的个人识别码PIN和/或所述第二设备的通信连接信息；

所述向所述第二设备发送第二请求，包括：

根据所述PIN和/或所述第二设备的通信连接信息向所述第二设备发送所述第二请求。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

接收第二响应，其中，所述第二响应用于指示所述第一设备的所述第一应用已加入所述第一群组。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

创建第二群组，其中，所述第二群组的成员包括所述第一设备的所述第一应用以及所述第二设备的所述第二应用。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

响应于用户在所述第一设备的第一应用的第一操作，显示第一弹框，所述第一弹框包括与所述第一设备处于同一个网络中的设备的标识；

所述向第二设备发送第一请求，包括：

响应于所述用户在所述第一弹框中选中所述第二设备的第二操作，向所述第二设备发送所述第一请求。

6.根据权利要求5所述的方法，其特征在于，

所述与所述第一设备处于同一个网络中的设备包括可信设备和不可信设备；其中，所述可信设备包括与所述第一设备登录同一个账号的设备、与所述第一设备进行过设备级认证的设备或者与所述第一设备的所述第一应用进行过应用级认证的设备；所述不可信设备包括未与所述第一设备登录同一个账号的设备、未与所述第一设备进行过设备级认证的设备或者未与所述第一设备的所述第一应用进行过应用级认证的设备。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述方法还包括：

扫描所述第二设备显示的二维码图片，所述二维码图片包括所述第一群组对应的个人识别码PIN和/或所述第二设备的通信连接信息，

所述向所述第二设备发送第二请求，包括：

8.根据权利要求1-7任一项所述的方法，其特征在于，将所述第一应用中的第一功能迁移到所述第二设备的所述第二应用包括：

向所述第二设备发送所述第一功能的业务信息；

当所述第一应用为直播应用时，所述第一功能的业务信息包括所述第一设备的直播间的视频流、音频流以及弹幕信息中的至少一种；或者

当所述第一应用为拍照应用时，所述第一功能的业务信息包括拍摄预览画面或拍摄界面的菜单栏信息；或者

当所述第一应用为K歌应用时，所述第一功能的业务信息包括歌名、歌词、歌曲的音频信息歌曲的视频信息、歌曲的控制界面中的至少一种；或者

当所述第一应用为购物应用时，所述第一功能的业务信息包括购物车中的商品信息；或者

当所述第一应用为邮件应用时，所述第一功能的业务信息包括邮件的主题、正文和附件中的至少一种。

9.一种功能迁移方法，其特征在于，应用于第二设备，所述方法包括：

接收来自第一设备的第一请求，所述第一请求携带所述第一设备的标识、第一应用的标识和第二应用的标识；

创建第一群组，所述第一群组的成员包括所述第二设备的所述第二应用；

向所述第一设备发送第一响应，所述第一响应用于指示所述第一群组；

接收来自所述第一设备的第二请求，所述第二请求用于申请将所述第一设备的所述第一应用加入所述第一群组。

接收所述第一设备迁移的所述第一应用中的第一功能，其中，所述第一功能包括一个或者多个图形用户界面UI。

10.根据权利要求9所述的方法，其特征在于，

所述第一响应包括所述第一群组对应的个人识别码PIN和/或所述第二设备的通信连接信息。

11.根据权利要求9或10所述的方法，其特征在于，所述方法还包括：

向所述第一设备发送第二响应，其中，所述第二响应用于指示所述第一设备的所述第一应用已加入所述第一群组。

12.根据权利要求9-11任一项所述的方法，其特征在于，所述从第一设备接收第一请求之后，所述方法还包括：

显示第一弹框，所述第一弹框用于提示用户是否同意将所述第一设备的所述第一应用加入所述第一群组；

接收来自用户的同意指令。

13.根据权利要求9-12任一项所述的方法，其特征在于，在所述创建第一群组之前，所述方法还包括：

根据所述第一设备的标识确定所述第二设备当前没有第二群组，其中，所述第二群组的成员包括所述第一设备和所述第二设备。

14.根据权利要求9-13任一项所述的方法，其特征在于，在所述创建第一群组之前，所述方法还包括：

根据所述第一设备的标识、所述第一应用的标识和所述第二应用的标识，确定所述第二设备当前没有第三群组，其中，所述第三群组的成员包括所述第一设备的所述第一应用以及所述第二设备的所述第二应用。

15.根据权利要求9-14任一项所述的方法，其特征在于，所述方法还包括：

显示二维码图片，所述二维码图片包括所述第一群组对应的个人识别码PIN和/或所述第二设备的通信连接信息。

16.根据权利要求9-15任一项所述的方法，其特征在于，所述接收所述第一设备迁移的所述第一应用中的第一功能包括：

接收来自所述第一设备的所述第一功能的业务信息；

17.一种终端，所述终端为第一设备，其特征在于，包括：处理器、近距离无线通信模块、存储器、以及一个或多个程序；其中，所述处理器和所述存储器耦合，所述处理器与所述近距离无线通信模块连接；所述一个或多个程序被存储在所述存储器中，所述一个或多个程序包括指令，所述指令用于执行如权利要求1-8任一项所述的方法。

18.一种终端，所述终端为第二设备，其特征在于，包括：处理器、近距离无线通信模块、存储器、以及一个或多个程序；其中，所述处理器和所述存储器耦合，所述处理器与所述近距离无线通信模块连接；所述一个或多个程序被存储在所述存储器中，所述一个或多个程序包括指令，所述指令用于执行如权利要求9-16任一项所述的方法。

19.一种计算机可读介质，用于存储一个或多个程序，其中所述一个或多个程序被配置为被所述一个或多个处理器执行，所述一个或多个程序包括指令，所述指令用于执行如权利要求1-8任一项或9-16任一项所述的方法。