A function migration method and device

Abstract

An embodiment of the present application provides a function migration method and apparatus, which relates to the field of terminals and can ensure the security and reliability of data sharing. The method is as follows: A first device sends a first request to a second device, and the first request carries the identifier of the first device; the second device receives the first request from the first device; the second device sends a first response to the first device, and the first response is used to indicate a first group created by the second device, and the members of the first group include the second device; the first device receives the first response from the second device; the first device sends a second request to the second device, and the second request is used to apply to join the first group by the first device; the first device migrates a first function in a first application to the second device, the first application is any application in the first device, and the first function includes one or more graphical user interfaces.

Description

Technical Field

[0001] This application relates to the field of terminals, and in particular, to a function migration method and apparatus. Background Art

[0002] With the popularization and development of digital devices such as smart phones, tablets, and personal computers (PCs), the number of personal terminals has increased sharply, and there is a need to share service data between different devices. Therefore, how to share service data to ensure the security and reliability of the data has become an urgent problem to be solved. Summary of the Invention

[0003] Embodiments of this application provide a function migration method and apparatus, which can ensure the security and reliability of data sharing.

[0004] In a first aspect, an embodiment of this application provides a function migration method, which is applied to a first device. The method includes: sending a first request to a second device, where the first request carries an identifier of the first device, an identifier of a first application, and an identifier of a second application; receiving a first response from the second device, where the first response is used to indicate a first group created by the second device, and members of the first group include the second application of the second device; sending a second request to the second device, where the second request is used to apply to add the first application of the first device to the first group; migrating a first function in the first application to the second application of the second device, where the first function includes one or more graphical user interfaces (UIs).

[0005] Based on the method provided by the embodiment of this application, through negotiation between the first device and the second device, the first application of the first device and the second application of the second device can be added to the first group, that is, the members of the first group can include the first application of the first device and the second application of the second device. Since the first group is established after negotiation between the first device and the second device, migrating functional data between the members of the first group, such as migrating one or more UIs of the first function, can ensure the security and reliability of data sharing.

[0006] In a possible implementation manner, the first response includes a personal identification number (PIN) corresponding to the first group and / or communication connection information of the second device; sending the second request to the second device includes: sending the second request to the second device according to the PIN and / or the communication connection information of the second device. In this way, when the first device needs to join a group created by the second device, the PIN corresponding to the group can be carried in the request, so that the second device can verify the security of the first device according to the PIN, thereby ensuring the security and reliability of data sharing.

[0007] In a possible implementation, the method further includes: receiving a second response, where the second response is used to indicate that a first application of a first device has joined a first group. In this way, the first device can learn that the first application has joined the first group, so that subsequent function migration can be directly performed.

[0008] In a possible implementation, the method further includes: creating a second group, where the members of the second group include the first application of the first device and the second application of the second device. That is, the first device can create a group locally (i.e., the second group), and this group is the same as the group created by the second device. In this way, when the second application of the second device performs function migration to the first application of the first device, if the first device determines that the second group is locally saved, it can be considered that the second application of the second device is secure and trustworthy, and function migration can be directly performed.

[0009] In a possible implementation, the method further includes: in response to a first operation of a user on a first application of a first device, displaying a first pop-up window, where the first pop-up window includes the identifiers of devices in the same network as the first device; sending a first request to a second device, including: in response to a second operation of the user selecting the second device in the first pop-up window, sending a first request to the second device. In this way, the first pop-up window can be used for the user to select the device for which function migration is to be performed.

[0010] In a possible implementation, the devices in the same network as the first device include trusted devices and untrusted devices; among them, the trusted devices include devices that log in to the same account as the first device, devices that have undergone device-level authentication with the first device, or devices that have undergone application-level authentication with the first application of the first device; the untrusted devices include devices that do not log in to the same account as the first device, devices that have not undergone device-level authentication with the first device, or devices that have not undergone application-level authentication with the first application of the first device. In this way, the user can be prompted with trusted devices and untrusted devices, facilitating the user to manage the corresponding devices.

[0011] In a possible implementation, the method further includes: scanning a two-dimensional code picture displayed by the second device, where the two-dimensional code picture includes a personal identification number (PIN) corresponding to the first group and / or the communication connection information of the second device, and sending a second request to the second device, including: sending a second request to the second device according to the PIN and / or the communication connection information of the second device. Here, the two-dimensional code picture is used as an identifier for illustration, and the two-dimensional code picture can be replaced with other types of identifiers, such as barcodes, strings, etc., which are not limited in this application.

[0012] In a possible implementation, migrating the first function in the first application to the second device includes: sending the service information of the first function to the second device; when the first application is a live broadcast application, the service information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live broadcast room on the first device; or when the first application is a camera application, the service information of the first function includes the shooting preview screen or the menu bar information of the shooting interface; or when the first application is a KTV application, the service information of the first function includes at least one of the song name, lyrics, audio information of the song, video information of the song, and control interface of the song; or when the first application is a shopping application, the service information of the first function includes the commodity information in the shopping cart; or when the first application is an email application, the service information of the first function includes at least one of the subject, body, and attachment of the email.

[0013] In this way, in different scenarios, some functions of different application programs (such as live broadcast applications, camera applications, KTV applications, email applications, or shopping applications) on the first device can be migrated to the second device, which can meet the requirements of cross-device function migration.

[0014] In a possible implementation, the communication connection information of the second device includes the Wi-Fi address or Bluetooth address of the second device.

[0015] In a possible implementation, the method further includes: sending a third request to a third device, where the third request carries the identifier of the first device, the package name of the first application, and the package name of the third application; the third request is used to request migrating the first function of the first application to the third application on the third device; receiving a second response, where the second response includes information indicating consent to the migration and the group name of the second group created by the third device, and the members of the second group include the first application on the first device and the third application on the third device; sending a fourth request to the third device, where the fourth request is used to apply to join the second group, and the fourth request includes the group name of the second group; migrating the first function in the first application to the third device.

[0016] In a possible implementation, the method further includes updating the members of the first group saved locally, and the updated members of the first group include the first application on the first device, the second application on the second device, and the third application on the third device.

[0017] In a possible implementation, the package name of the second application is the same as the package name of the first application.

[0018] In a possible implementation, the trusted device includes a third device. In response to an operation by the user to delete the third device from the trusted device, the group associated with the third device is deleted.

[0019] In a possible implementation, the first group is set to be permanently valid or valid within a preset time.

[0020] In a possible implementation, when the first application is a KTV application, the method further includes: rearranging the song selection control UI; in response to an operation by the user to select a song or switch songs on the song selection control UI, sending the song selection and song switching information to the second device.

[0021] In a possible implementation, when the first application is a shopping application, the service information of the first function includes the product information in the shopping cart, and the product information includes at least one of the product name, product link, and product price information.

[0022] In a possible implementation, when the first application is an email application, the service information of the first function includes at least one of the subject, body, or attachment of the email.

[0023] In a second aspect, an embodiment of the present application provides a function migration method, which is applied to a second device. The method includes: receiving a first request from a first device, where the first request carries the identifier of the first device, the identifier of the first application, and the identifier of the second application; creating a first group, where the members of the first group include the second application of the second device; sending a first response to the first device, where the first response is used to indicate the first group; receiving a second request from the first device, where the second request is used to apply to add the first application of the first device to the first group. Receiving the first function in the first application migrated from the first device, where the first function includes one or more graphical user interfaces (UIs).

[0024] Based on the method provided by the embodiment of the present application, through negotiation between the first device and the second device, the first application of the first device and the second application of the second device can be added to the first group, that is, the members of the first group can include the first application of the first device and the second application of the second device. Since the first group is established after negotiation between the first device and the second device, migrating function data between the members of the first group, such as migrating one or more UIs of the first function, can ensure the security and reliability of data sharing.

[0025] In a possible implementation, the first response includes the personal identification number (PIN) corresponding to the first group and / or the communication connection information of the second device. In this way, the second device can verify the security of the first device according to the PIN, thereby ensuring the security and reliability of data sharing.

[0026] In a possible implementation, the method further includes: sending a second response to the first device, where the second response is used to indicate that the first application of the first device has joined the second group. In this way, the first device can learn that the first application has joined the first group, so that subsequent function migration can be directly performed.

[0027] In a possible implementation, after receiving the first request from the first device, the method further includes: displaying a first pop-up window, where the first pop-up window is used to prompt the user whether to agree to add the first application of the first device to the first group; receiving an approval instruction from the user. In this way, the user can be prompted by the first pop-up window to add the first application of the first device to the first group.

[0028] In a possible implementation, before creating the first group, the method further includes: determining, according to the identifier of the first device, that the second device currently does not have a second group, where the members of the second group include the first device and the second device. That is, when it is determined that there is no group established between the first device and the second device, that is, when there is no prior establishment of a process trusted connection between the first device and the second device, the first group can be created.

[0029] In a possible implementation, before creating the first group, the method further includes: determining, according to the identifier of the first device, the identifier of the first application, and the identifier of the second application, that the second device currently does not have a third group, where the members of the third group include the first application of the first device and the second application of the second device. That is, when it is determined that there is no group established between the first application of the first device and the second application of the second device, that is, when there is no prior establishment of a process trusted connection between the first application of the first device and the second application of the second device, the first group can be created.

[0030] In a possible implementation, the method further includes: displaying a QR code picture, where the QR code picture includes the personal identification number (PIN) corresponding to the first group and / or the communication connection information of the second device. Here, the QR code picture is used as an identifier for illustration, and the QR code picture can be replaced with other types of identifiers, such as barcodes, strings, etc., which are not limited in this application.

[0031] In a possible implementation, receiving the first function in the first application migrated by the first device includes: receiving the service information of the first function from the first device; when the first application is a live broadcast application, the service information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live broadcast room of the first device; or when the first application is a camera application, the service information of the first function includes the shooting preview screen or the menu bar information of the shooting interface; or when the first application is a KTV application, the service information of the first function includes at least one of the song name, lyrics, audio information of the song, video information of the song, and control interface of the song; or when the first application is a shopping application, the service information of the first function includes the product information in the shopping cart; or when the first application is an email application, the service information of the first function includes at least one of the subject, body, and attachment of the email.

[0032] In this way, in different scenarios, some functions of different application programs (such as live broadcast applications, camera applications, KTV applications, email applications, or shopping applications) on the first device can be migrated to the second device, which can meet the requirements of cross-device migration functions.

[0033] In a possible implementation, the communication connection information of the second device includes the Wi-Fi address or Bluetooth address of the second device.

[0034] In a possible implementation, the package name of the second application is the same as the package name of the first application.

[0035] In a possible implementation, the first group is set to be permanently valid or valid within a preset time.

[0036] In a possible implementation, after receiving the first request from the first device, the method further includes: displaying a second pop-up window for prompting the user whether to agree that the first device migrates the first function to the second device.

[0037] In a possible implementation, if the second device installs a live broadcast application, the second device detects whether the live broadcast application is logged in; if the live broadcast application is in a logged-in state, the live broadcast application displays the first function on the live broadcast screen of the second device.

[0038] In a possible implementation, if the second device does not install a live broadcast application, the second device displays the first function in the form of an audio player.

[0039] In a possible implementation, when the first application is a camera application, the service information of the first function includes the shooting preview screen and the menu bar information of the shooting interface.

[0040] In a possible implementation, the second device displays the shooting preview screen of the first device and the menu bar of the shooting interface; in response to the user's operation on the second device to trigger the first device to take a photo or video, a shooting instruction is sent to the first device, and the first device takes a photo or video.

[0041] In a possible implementation, when the first application is a KTV application, if the KTV application is installed on the second device, it is detected whether the KTV application is logged in; if the KTV application is in the logged-in state, the KTV application displays the first function.

[0042] In a possible implementation, when the first application is a KTV application, if the KTV application is not installed on the second device, the first function is displayed in the form of an audio player.

[0043] In a possible implementation, when the first application is a shopping application, if the shopping application is installed on the second device, it is detected whether the shopping application is logged in; if the shopping application is in the logged-in state, the shopping application displays a shared shopping cart according to the service information of the first function, and the shared shopping cart includes all the items in the shopping cart of the second device and all the items in the shopping cart of the first device.

[0044] In a possible implementation, in response to the user's operation of settling all the items in the shared shopping cart, the second device sends a payment request to the first device, and the payment request includes the total amount of all the items in the shopping cart of the first device.

[0045] In a possible implementation, when the first application is an email application, if the email application is installed on the second device, it is detected whether the email application is logged in; if the email application is in the logged-in state, the email application displays the first function.

[0046] In a possible implementation, when the first application is an email application, if the email application is not installed on the second device, the first function is encoded and rearranged for display in the form of a text and graphics editor.

[0047] In a third aspect, an embodiment of the present application provides a function migration method, which is applied to a communication system including a first device and a second device. The method includes: the first device sends a first request to the second device, and the first request carries the identifier of the first device; the second device receives the first request from the first device; the second device sends a first response from the first device, and the first response is used to indicate a first group created by the second device, and the members of the first group include the second device; the first device receives the first response from the second device; the first device sends a second request to the second device, and the second request is used to apply to join the first group by the first device; the first device migrates the first function in the first application to the second device, the first application is any application in the first device, and the first function includes one or more graphical user interfaces (UIs).

[0048] In a possible implementation, the first response includes the personal identification number (PIN) corresponding to the first group and / or the communication connection information of the second device. Sending a second request to the second device includes: sending a second request to the second device according to the PIN and / or the communication connection information of the second device. The method further includes: receiving a second response from the second device, where the second response is used to indicate that the first device has joined the first group.

[0049] In a possible implementation, in response to a first operation of the user, the first device displays a first pop-up window, and the first pop-up window includes the identifiers of one or more devices that have not been authenticated with the first device. Sending a first request from the first device to the second device includes: sending a first request to the second device in response to a second operation of the user selecting the second device in the first pop-up window.

[0050] In a possible implementation, the method further includes: the first device creates a second group, and the members of the second group include the first device and the second device.

[0051] In a possible implementation, the method further includes: in response to a first operation of the user on a first application of the first device, the first device displays a first pop-up window, and the first pop-up window includes the identifiers of devices in the same network as the first device. Sending a first request from the first device to the second device includes: the first device sends a first request to the second device in response to a second operation of the user selecting the second device in the first pop-up window.

[0052] In a possible implementation, the devices in the same network as the first device include trusted devices and untrusted devices. Among them, trusted devices include devices that log in to the same account as the first device, devices that have undergone device-level authentication with the first device, or devices that have undergone application-level authentication with the first application of the first device. Untrusted devices include devices that do not log in to the same account as the first device, devices that have not undergone device-level authentication with the first device, or devices that have not undergone application-level authentication with the first application of the first device.

[0053] In a possible implementation, the method further includes: the second device displays a QR code picture, and the QR code picture includes the personal identification number (PIN) corresponding to the first group and / or the communication connection information of the second device. The first device scans the QR code picture displayed by the second device. Sending a second request from the first device to the second device includes: the first device sends a second request to the second device according to the PIN and / or the communication connection information of the second device.

[0054] In a possible implementation, the first device migrating the first function in the first application to the second device includes: sending the service information of the first function to the second device; when the first application is a live broadcast application, the service information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live broadcast room of the first device; or when the first application is a photo-taking application, the service information of the first function includes the shooting preview screen or the menu bar information of the shooting interface; or when the first application is a KTV application, the service information of the first function includes at least one of the song name, lyrics, audio information of the song, video information of the song, and control interface of the song; or when the first application is a shopping application, the service information of the first function includes the commodity information in the shopping cart; or when the first application is a mail application, the service information of the first function includes at least one of the subject, body, and attachment of the mail.

[0055] In a fourth aspect, an embodiment of the present application provides a function migration method, which is applied to a first device and includes: creating a first group, where the members of the first group include the first application of the first device; receiving a first request from a second device, where the first request is used to apply to add the second application of the second device to the first group; adding the second application of the second device to the first group; migrating the first function in the first application to the second application of the second device, and the second function includes one or more graphical user interfaces (UIs).

[0056] In a possible implementation, before receiving the first request from the second device, the method further includes: displaying a first identifier for indicating the first group, where the first request corresponds to the first identifier.

[0057] In a possible implementation, the first identifier includes a two-dimensional code picture, and the first identifier includes a personal identification number (PIN); after receiving the first request from the second device, the method further includes: determining that the PIN is carried in the first request; determining to add the second application of the second device to the first group.

[0058] In a possible implementation, migrating the first function in the first application to the second application of the second device includes: sending the service information of the first function to the second device; when the first application is a live broadcast application, the service information of the first function includes at least one of the video stream, audio stream, and bullet screen information of the live broadcast room of the first device; or when the first application is a photo-taking application, the service information of the first function includes the shooting preview screen or the menu bar information of the shooting interface; or when the first application is a KTV application, the service information of the first function includes at least one of the song name, lyrics, audio information of the song, video information of the song, and control interface of the song; or when the first application is a shopping application, the service information of the first function includes the commodity information in the shopping cart; or when the first application is a mail application, the service information of the first function includes at least one of the subject, body, and attachment of the mail.

[0059] In a fifth aspect, an embodiment of the present application provides a function migration method, which is applied to a second device and includes: sending a first request to a first device, where the first request is used to apply to add a second application of the second device to a first group created by the first device, and the members of the first group include a first application of the first device and a second application of the second device; receiving a first function in the first application from the first device, where the first function includes one or more graphical user interfaces (UIs).

[0060] In a possible implementation, before sending the first request to the first device, the method further includes: scanning a first identifier for indicating the first group, where the first request corresponds to the first identifier.

[0061] In a possible implementation, the first identifier includes a QR code picture, and the first identifier includes a personal identification number (PIN); sending the first request to the first device includes: sending the first request to the first device, where the PIN is carried in the first request.

[0062] In a possible implementation, receiving the first function in the first application from the first device includes: receiving service information of the first function from the first device; when the first application is a live broadcast application, the service information of the first function includes at least one of a video stream, an audio stream, and bullet screen information of a live broadcast room of the first device; or when the first application is a photo-taking application, the service information of the first function includes a shooting preview screen or menu bar information of a shooting interface; or when the first application is a karaoke application, the service information of the first function includes at least one of a song name, lyrics, audio information of the song, video information of the song, and a control interface of the song; or when the first application is a shopping application, the service information of the first function includes product information in a shopping cart; or when the first application is an email application, the service information of the first function includes at least one of a subject, a body, and an attachment of an email.

[0063] In a sixth aspect, the present application provides a first device, including one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, and the computer program code includes computer instructions. When the one or more processors execute the computer instructions, the first device is caused to execute the method in any possible implementation manner of any item in the first aspect, the third aspect, or the fourth aspect above.

[0064] In a seventh aspect, the present application provides a second device, including one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are configured to store computer program code, where the computer program code includes computer instructions. When the one or more processors execute the computer instructions, the second device is caused to execute the method in any possible implementation manner of any item in the above-mentioned second aspect, third aspect, or fifth aspect.

[0065] In an eighth aspect, an embodiment of the present application provides a computer program product, which, when running on a computer, causes the computer to execute the method in any possible implementation manner of any item in the above-mentioned aspects.

[0066] In a ninth aspect, the present application provides a chip system, which can be disposed in a first device. The chip system includes one or more interface circuits and one or more processors. The interface circuits and the processors are interconnected by lines. The chip system can be applied to an electronic device including a communication module and a memory. The interface circuit is configured to receive a signal from the memory and send the received signal to the processor, where the signal includes computer instructions stored in the memory. When the processor executes the computer instructions, the first device can execute the method described in any of the above aspects and any possible implementation manner thereof.

[0067] In a tenth aspect, an embodiment of the present application provides a computer storage medium, including computer instructions, which, when running on a first device, cause the first device to execute the method in any possible implementation manner of any item in the above-mentioned aspects.

[0068] In an eleventh aspect, an embodiment of the present application provides a function migration system, including at least two devices (such as a first device and a second device), and each device can execute the method described in any of the above aspects and any possible implementation manner thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] Figure 1 FIG. is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0070] Figure 2 FIG. is another schematic diagram of a system architecture provided by an embodiment of the present application;

[0071] Figure 3 FIG. is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present application;

[0072] Figure 4 FIG. is a schematic diagram of the software architecture of an electronic device provided by an embodiment of the present application;

[0073] Figure 5A FIG. is a schematic diagram of a display provided by an embodiment of the present application;

[0074] Figure 5B Another display schematic diagram provided by the embodiment of the present application;

[0075] Figure 5C Another display schematic diagram provided by the embodiment of the present application;

[0076] Figure 5D Another display schematic diagram provided by the embodiment of the present application;

[0077] Figure 5E Another display schematic diagram provided by the embodiment of the present application;

[0078] Figure 5F Another display schematic diagram provided by the embodiment of the present application;

[0079] Figure 6A Another display schematic diagram provided by the embodiment of the present application;

[0080] Figure 6B Another display schematic diagram provided by the embodiment of the present application;

[0081] Figure 6C Another display schematic diagram provided by the embodiment of the present application;

[0082] Figure 7A A signal interaction schematic diagram provided by the embodiment of the present application;

[0083] Figure 7B Another signal interaction schematic diagram provided by the embodiment of the present application;

[0084] Figure 7C Another signal interaction schematic diagram provided by the embodiment of the present application;

[0085] Figure 8A Another display schematic diagram provided by the embodiment of the present application;

[0086] Figure 8B Another display schematic diagram provided by the embodiment of the present application;

[0087] Figure 8C Another display schematic diagram provided by the embodiment of the present application;

[0088] Figure 8D Another display schematic diagram provided by the embodiment of the present application;

[0089] Figure 8E Another display schematic diagram provided by the embodiment of the present application;

[0090] Figure 9A Another signal interaction schematic diagram provided by the embodiment of the present application;

[0091] Figure 9B Another signal interaction schematic diagram provided by the embodiment of the present application;

[0092] Figure 9C Another signal interaction schematic diagram provided by the embodiment of the present application;

[0093] Figure 10A Another display schematic diagram provided by the embodiment of the present application;

[0094] Figure 10B Another display schematic diagram provided by the embodiment of the present application;

[0095] Figure 11 Another signal interaction schematic diagram provided by the embodiment of the present application;

[0096] Figure 12A Another display schematic diagram provided by the embodiment of the present application;

[0097] Figure 12B Another display schematic diagram provided by the embodiment of the present application;

[0098] Figure 12C Another display schematic diagram provided by the embodiment of the present application;

[0099] Figure 12D Another display schematic diagram provided by the embodiment of the present application;

[0100] Figure 12E Another display schematic diagram provided by the embodiment of the present application;

[0101] Figure 12F Another display schematic diagram provided by the embodiment of the present application;

[0102] Figure 13 Another signal interaction schematic diagram provided by the embodiment of the present application;

[0103] Figure 14A Another display schematic diagram provided by the embodiment of the present application;

[0104] Figure 14B Another display schematic diagram provided by the embodiment of the present application;

[0105] Figure 14C Another display schematic diagram provided by the embodiment of the present application;

[0106] Figure 14D Another display schematic diagram provided by the embodiment of the present application;

[0107] Figure 14E Another display schematic diagram provided by the embodiment of the present application;

[0108] Figure 14F Another display schematic diagram provided by the embodiment of the present application;

[0109] Figure 15 Another signal interaction schematic diagram provided by the embodiment of the present application;

[0110] Figure 16A Another display schematic diagram provided by the embodiment of the present application;

[0111] Figure 16B Another display schematic diagram provided by the embodiment of the present application;

[0112] Figure 16C Another display schematic diagram provided by the embodiment of the present application;

[0113] Figure 16D Another display schematic diagram provided by the embodiment of the present application;

[0114] Figure 16E Another display schematic diagram provided by the embodiment of the present application;

[0115] Figure 17A Another signal interaction schematic diagram provided by the embodiment of the present application;

[0116] Figure 17B Another display schematic diagram provided by the embodiment of the present application;

[0117] Figure 17C Another display schematic diagram provided by the embodiment of the present application;

[0118] Figure 17D Another display schematic diagram provided by the embodiment of the present application;

[0119] Figure 18A Another display schematic diagram provided by the embodiment of the present application;

[0120] Figure 18B Another display schematic diagram provided by the embodiment of the present application;

[0121] Figure 18C Another display schematic diagram provided by the embodiment of the present application;

[0122] Figure 18D Another display schematic diagram provided by the embodiment of the present application;

[0123] Figure 19 Another signal interaction schematic diagram provided by the embodiment of the present application;

[0124] Figure 20 Another signal interaction schematic diagram provided by the embodiment of the present application;

[0125] Figure 21 Another signal interaction schematic diagram provided by an embodiment of the present application;

[0126] Figure 22 Another signal interaction schematic diagram provided by an embodiment of the present application;

[0127] Figure 23 A schematic structural diagram of a chip system provided by an embodiment of the present application. Detailed implementation manners

[0128] The system architecture involved in the embodiments of the present application may include multiple electronic devices. The multiple electronic devices can be networked, and after networking, information interaction can be carried out between the multiple electronic devices. The networking methods include but are not limited to the following methods:

[0129] (1) Wireless Fidelity (Wi-Fi) networking method: Multiple electronic devices can be connected to the same routing device (for example, a router). As Figure 1 shown, mobile phone 101, mobile phone 102, tablet computer 103, laptop computer 104, and smart TV 105 can be connected to router 106 to form a home network. Or, multiple electronic devices can join the same hotspot device (for example, connect to the hotspot of the same mobile phone). At this time, the information interaction between the electronic devices can be forwarded by the hotspot device. For example, mobile phone 102, tablet computer 103, laptop computer 104, and smart TV 105 can be connected to mobile phone 101 to form a hotspot network, and mobile phone 101 can be used as the hotspot device to forward information for each electronic device.

[0130] (2) Bluetooth networking method: Multiple electronic devices can be connected to the same Bluetooth device (for example, mobile phone 101). At this time, the information interaction between the electronic devices can be forwarded by the Bluetooth device. As Figure 2 shown, mobile phone 101, tablet computer 103, laptop computer 104, and smart TV 105 can be connected to mobile phone 102 to form a Bluetooth network, and mobile phone 101 can be used as the Bluetooth device to forward information for each electronic device.

[0131] Multiple electronic devices can adopt multiple networking methods. For example, they can adopt the Wireless Fidelity networking method and the Bluetooth networking method at the same time. The present application does not make any limitations.

[0132] As Figure 3As shown in the figure, in the embodiment of the present application, taking the electronic device 200 (such as a mobile phone) as an example, the structure of the electronic device provided in the embodiment of the present application is illustrated. The electronic device 200 (such as a mobile phone) may include: a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, a sensor module 280, a button 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a subscriber identification module (SIM) card interface 295, etc.

[0133] Among them, the above-mentioned sensor module 280 may include sensors such as a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, and a bone conduction sensor.

[0134] It can be understood that the structure schematically shown in this embodiment does not constitute a specific limitation on the electronic device 200. In other embodiments, the electronic device 200 may include more or fewer components than those shown in the figure, or combine certain components, or split certain components, or have different component arrangements. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0135] The processor 210 may include one or more processing units. For example, the processor 210 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units may be independent devices or integrated in one or more processors.

[0136] The controller may be the nerve center and command center of the electronic device 200. The controller may generate operation control signals according to the instruction operation code and timing signals to complete the control of fetching instructions and executing instructions.

[0137] A memory may also be provided in the processor 210 for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. This memory can hold the instructions or data that the processor 210 has just used or recycled. If the processor 210 needs to use the instruction or data again, it can be directly called from the memory. This avoids repeated accesses and reduces the waiting time of the processor 210, thus improving the efficiency of the system.

[0138] In some embodiments, the processor 210 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0139] It can be understood that the interface connection relationships between the modules illustrated in this embodiment are only illustrative and do not constitute a structural limitation on the electronic device 200. In other embodiments, the electronic device 200 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0140] The charging management module 240 is configured to receive a charging input from a charger. The charger may be a wireless charger or a wired charger. While charging the battery 242, the charging management module 240 can also supply power to the electronic device through the power management module 241.

[0141] The power management module 241 is used to connect the battery 242, the charging management module 240, and the processor 210. The power management module 241 receives the inputs from the battery 242 and / or the charging management module 240 and supplies power to the processor 210, the internal memory 221, the external memory, the display screen 294, the camera 293, the wireless communication module 260, etc. In some embodiments, the power management module 241 and the charging management module 240 may also be provided in the same device.

[0142] The wireless communication function of the electronic device 200 can be implemented by the antenna 1, the antenna 2, the mobile communication module 250, the wireless communication module 260, the modulation and demodulation processor, and the baseband processor, etc. In some embodiments, the antenna 1 of the electronic device 200 is coupled to the mobile communication module 250, and the antenna 2 is coupled to the wireless communication module 260, so that the electronic device 200 can communicate with the network and other devices through wireless communication technologies.

[0143] The antenna 1 and the antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device 200 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization rate of the antennas. For example, the antenna 1 can be multiplexed as the diversity antenna of the wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0144] The mobile communication module 250 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc. applied to the electronic device 200. The mobile communication module 250 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 250 can receive electromagnetic waves from the antenna 1, filter, amplify, etc. the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation.

[0145] The mobile communication module 250 can also amplify the signal modulated by the modulation and demodulation processor and convert it into electromagnetic waves through the antenna 1 for radiation. In some embodiments, at least some functional modules of the mobile communication module 250 may be provided in the processor 210. In some embodiments, at least some functional modules of the mobile communication module 250 and at least some modules of the processor 210 may be provided in the same device.

[0146] The wireless communication module 260 may provide wireless communication solutions applied to the electronic device 200, including WLAN (such as wireless fidelity (Wi-Fi) network), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), etc.

[0147] The wireless communication module 260 may be one or more devices integrating at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on the electromagnetic wave signals, and sends the processed signals to the processor 210. The wireless communication module 260 may also receive the signals to be sent from the processor 210, perform frequency modulation and amplification on them, and convert them into electromagnetic waves through the antenna 2 for radiation.

[0148] The electronic device 200 realizes the display function through the GPU, the display screen 294, and the application processor, etc. The GPU is a microprocessor for image processing, connected to the display screen 294 and the application processor. The GPU is used to execute mathematical and geometric calculations for graphics rendering. The processor 210 may include one or more GPUs, which execute program instructions to generate or change display information.

[0149] The display screen 294 is used to display images, videos, etc. The display screen 294 includes a display panel.

[0150] The electronic device 200 can realize the shooting function through the ISP, the camera 293, the video codec, the GPU, the display screen 294, and the application processor, etc. The ISP is used to process the data fed back by the camera 293. The camera 293 is used to capture static images or videos. In some embodiments, the electronic device 200 may include one or N cameras 293, where N is a positive integer greater than 1.

[0151] The external memory interface 220 may be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 200. The external memory card communicates with the processor 210 through the external memory interface 220 to achieve the data storage function. For example, files such as music and videos are saved in the external memory card.

[0152] The internal memory 221 can be used to store computer-executable program codes, and the executable program codes include instructions. The processor 210 executes various functional applications and data processing of the electronic device 200 by running the instructions stored in the internal memory 221. For example, in the embodiments of the present application, the processor 210 can execute the instructions stored in the internal memory 221, and the internal memory 221 can include a program storage area and a data storage area.

[0153] Among them, the program storage area can store an operating system, application programs required for at least one function (such as a sound playback function, an image playback function, etc.). The data storage area can store data created during the use of the electronic device 200 (such as audio data, a phone book, etc.). In addition, the internal memory 221 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0154] The electronic device 200 can implement audio functions through an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, and an application processor, etc. Such as music playback, recording, etc.

[0155] The keys 290 include a power-on key, a volume key, etc. The keys 290 can be mechanical keys or touch keys. The motor 291 can generate a vibration prompt. The motor 291 can be used for incoming call vibration prompts and can also be used for touch vibration feedback. The indicator 292 can be an indicator light, which can be used to indicate the charging state, the change in battery power, and can also be used to indicate messages, missed calls, notifications, etc. The SIM card interface 295 is used to connect the SIM card. The SIM card can be inserted into or removed from the SIM card interface 295 to achieve contact and separation from the electronic device 200. The electronic device 200 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 295 can support Nano SIM cards, Micro SIM cards, SIM cards, etc.

[0156] As Figure 4 shown, the software structure of the electronic device provided in the embodiments of the present application is illustrated by way of example. The software architecture of the electronic device can include an application layer, an application framework layer, a hardware abstraction layer (HAL), and a driver layer. The embodiments of the present application take the operating system of the electronic device as a dual-frame operating system (i.e., the Android system and the HarmonyOS) as an example for illustration. The electronic device can also be an Android system, a HarmonyOS, an IOS system, or other operating systems, which are not limited in the embodiments of the present application.

[0157] Among them, the application layer may include Android applications and HarmonyOS applications. Among them, Android applications may include a device manager kit and a distributed execute framework (DEF) kit. Among them, the kit (service) may be a software development kit (SDK) for providing basic services to applications in the application layer. The DM kit may include a device discovery module, a trusted device maintenance module, a device authentication module, a device screening and sorting module, etc. HarmonyOS applications may include a DM kit and a HarmonyOS SDK. Among them, the SDK may refer to a collection of related documents, examples, and tools for assisting in the development of a certain type of software.

[0158] Among them, the DM kit may include a device discovery module, a trusted device maintenance module, a device authentication module, a device screening and sorting module, etc. Optionally, the application layer may further include applications such as a camera, a gallery, a calendar, a call, a map, a navigation, a WLAN, a Bluetooth, a music, a video, a short message, etc., which are not limited in this application.

[0159] The application framework layer may include DM, DEF, a distributed scheduler manager Service (DMS), a two-dimensional code recognition module (hivision), a HarmonyOS label management module, a security management module, a communication module, and a device profile. Of course, the framework layer 302 may further include an activity manager, a window manager, a content provider, a resource manager, a notification manager, etc., which are not limited in the embodiments of this application.

[0160] Among them, the device management module (DM module): mainly provides device discovery, trusted device maintenance, and device authentication capabilities. By maintaining local device information, writing the information into a two-dimensional code, scanning and identifying the code, establishing a physical connection, and maintaining device group information, a secure and trusted connection is established between devices with the same account or different accounts, and between Android and HarmonyOS devices. Optionally, the DM may include a device discovery module, a trusted device maintenance module, a device authentication module, and a device sorting and screening module. The device discovery module is used for processing such as sending a broadcast, discovering a device, encapsulating device information, and popping up a device list UI. The trusted device maintenance module is used for processing such as querying a trusted device list, writing trusted device information, maintaining the trusted device list, and listening for the online and offline status of trusted devices. The device authentication module is used for processing such as underlying channel management, access control, a PIN code mechanism, and group management. The device sorting and screening module is used for processing such as device screening and device sorting.

[0161] HarmonyOS Label Management Module: Responsible for providing capabilities such as HarmonyOS label application, parsing, formatting, HarmonyOS label service query, and service distribution.

[0162] Distributed Execution Framework (DEF): Responsible for providing discovery, registration, query, and migration of atomic services; responsible for underlying data communication and device discovery between devices.

[0163] QR Code Recognition Module: Provides HarmonyOS label generation and scanning capabilities. Generates HarmonyOS QR code labels through the label information provided by the label service, and triggers the label service to parse the label information by scanning the HarmonyOS QR code labels.

[0164] Security Management Module (HiChain): Manages groups in a distributed scenario and device group authentication; groups include public groups and application-level private groups. Provides secure and trusted communication and connection between devices and between applications in a distributed scenario.

[0165] Communication Module (communication): The soft bus manages the self-discovery and self-networking of devices with the same account in a distributed scenario; scans and discovers devices with different accounts; provides a communication channel for communication between different devices to ensure the secure and stable transmission of data.

[0166] DMS: Mainly completes cross-device service binding and cross-device Android Interface Definition Language (AIDL) interface call capabilities. AIDL is a description language used to define the communication interface between the server and the client.

[0167] Device Information Database: Responsible for reading, writing, storing, and managing device information.

[0168] HAL may include a microphone, a speaker, a Wi-Fi module, a Bluetooth module, a camera, a sensor, etc.

[0169] The driver layer is the layer between the hardware and the software, and can also be called the kernel layer. The kernel layer at least includes a display driver, a camera driver, an audio driver, and a sensor driver.

[0170] The above software architecture can be deployed on multiple electronic devices in the current networking environment (for example, such as Figure 1 or Figure 2 the mobile phone 101, mobile phone 102, tablet 103, laptop 104, smart TV 105, router 106, etc. in

[0171] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. Among them, in the description of the present application, unless otherwise specified, "at least one" means one or more, and "a plurality" means two or more. In addition, in order to clearly describe the technical solutions in the embodiments of the present application, in the embodiments of the present application, terms such as "first" and "second" are used to distinguish the same items or similar items with basically the same functions and roles. Those skilled in the art can understand that the terms such as "first" and "second" do not limit the quantity and execution order, and the terms such as "first" and "second" do not necessarily limit to be different.

[0172] For the sake of clear and concise description of the following embodiments, a brief introduction to relevant concepts or technologies is given first:

[0173] Ability: Ability is an abstraction of the capabilities possessed by an application. An application can contain one or more Abilities. HarmonyOS supports the deployment of applications in units of Abilities. Abilities are divided into two types: FAs (Feature Abilities) and AAs (Meta Abilities).

[0174] AA: A program entity developed by a third party based on HarmonyOS services to implement a single function, used to provide the ability to run background tasks, without a UI interface. AAs have the characteristics of multi-device deployment and distributed execution. AAs have a dependency relationship with system services, and there is no dependency relationship between AAs.

[0175] FA: Used to provide the ability (function) to interact with users. An FA can contain a set of related pages (which can also be considered as a set of UIs), and each page can be represented by an AbilitySlice instance. An FA can be a program entity that realizes complex functions by calling AAs. It is developed based on a new structure of separation of interface / data / logic, and can be independently packaged and put on the shelf. FAs have the following capabilities: installation-free, running independently from the application, cross-device UI migration, cross-device binary migration, etc. The UI interface of FAs is somewhat similar to that of mini-programs or instant apps, but is essentially different. The differences can include two points. One is that FAs can be migrated across devices (for example, an FA on mobile phone A can be migrated to mobile phone B, so that mobile phone B can control this FA on mobile phone A); the other is that FAs can be cross-platform. For example, FAs can run on both Android systems and HarmonyOS systems, while current mini-programs or instant apps usually run on Android systems.

[0176] Currently, FA sharing technology can be used to share FAs between different devices, that is, an FA on one device can be migrated to another device for display and operation. Before sharing an FA, authentication is required to ensure the security and reliability of FA sharing.

[0177] An embodiment of the present application provides a function migration method, including device-level authentication and application-level authentication. After application-level authentication between different devices, specific applications between different devices can communicate with each other (i.e., applications can exchange business data, such as migrating FA). For example, after mutual authentication between the first application of device A and the first application of device B, the first application of device A and the first application of device B can communicate with each other, but other applications of device A (such as the second application) and other applications of device B (such as the second application) cannot communicate with each other. After device-level authentication, all applications between different devices can communicate with each other.

[0178] For ease of understanding, the user interface (UI) of device-level authentication provided in the embodiment of the present application is introduced below using mobile phone A and mobile phone B as examples.

[0179] like Figure 5A As shown in (a) of Figure 5, the user can access the Smart Collaboration interface 501 from the Settings app. Smart Collaboration interface 501 includes a list titled "My Devices." "My Devices" includes this device (i.e., phone A), Kiki's Mate pad, and Kiki's Mate book pro. This device, Kiki's Mate pad, and Kiki's Mate book pro can be devices with the same account (for example, sharing a Huawei account). Alternatively, this device, Kiki's Mate pad, and Kiki's Mate book pro can be devices with different accounts but authenticated (the authentication process is described below).

[0180] Optionally, the smart collaboration interface 501 may include a bind other device button 502. In the embodiment of the present application, binding refers to establishing a trusted relationship between two devices so that any applications of the two devices can communicate with each other, for example, FA can be migrated to each other without authentication. In response to the user's operation on the bind other device button 502 (for example, a click operation), as shown in FIG. Figure 5A As shown in (b) in FIG, mobile phone A may display a tap-to-add button 503 and a scan-to-add button 504. It should be understood that Figure 5A The positions, names and shapes of the elements (e.g., buttons, icons, text, etc.) in the UI interface corresponding to (a) and (b) are not fixed and can be freely combined or designed according to needs. For example, Figure 5A The button 502 in (a) can be replaced by Figure 5A Button 503 and button 504 in (b).

[0181] For example, in response to the user's click operation on the touch add button 503, as shown in FIG. Figure 5BAs shown in (a) of [Figure ID], mobile phone A can display a "Tap to Add" interface 505. In the "Tap to Add" interface 505, a pop-up window 506 can be displayed. The pop-up window 506 includes a prompt picture and a prompt message. The prompt message can be, for example: "Tap to add. After the mobile phone enables NFC, tap the ontag label on the device with the back of the phone." The user can operate according to the prompt message to add a new device by tapping. For another example, in response to the user's click operation on the "Scan to Add" button 504, as Figure 5B shown in (b) of [Figure ID], mobile phone A can display a "Scan to Add" interface 507. The "Scan to Add" interface 507 can include a prompt picture and a prompt message. The prompt message can be, for example: "Scan the QR code on the device or the package." The user can operate according to the prompt message to add a new device by scanning.

[0182] If mobile phone A does not support adding new devices by tapping and scanning, as Figure 5C shown in (a) of [Figure ID], in response to the user's click operation on the "Bind Other Devices" button 502, as Figure 5C shown in (b) of [Figure ID], mobile phone A can display a pop-up window 508. The pop-up window 508 includes a prompt message "Please ensure that the device is turned on and near the mobile phone". The pop-up window 508 can also include devices detected by mobile phone A based on a short-range communication network (for example, a Wi-Fi network or a Bluetooth network), such as a room TV, HUAWEI P20, and Mate book X pro, etc. Each device corresponds to a binding button. In response to the user's operation on the binding button 509 corresponding to HUAWEI P20, as Figure 5D shown in (a) of [Figure ID], a prompt message 510 "Waiting for confirmation from the other end..." can be displayed below the identifier of HUAWEI P20. The pop-up window 508 can also have a cancel button 511. In response to the user's click operation on the cancel button 511, mobile phone A can return to the interface as Figure 5C shown in (a) of [Figure ID].

[0183] If the peer device confirms (for example, the user of the peer device agrees to bind), as Figure 5D shown in (b) of [Figure ID], mobile phone A can display a "Bind New Device" interface 512. The "Bind New Device" interface 512 can include a prompt message "Scan the QR code displayed by the peer". The user can operate according to the prompt message to add a new device. It should be understood that the embodiments of the present application do not limit the jump relationship between different UI interfaces. For example, as Figure 5C shown in (b) of [Figure ID], in response to the user's click operation on the binding button 509, as Figure 5D shown in (b) of [Figure ID], the mobile phone can directly display a scanning interface 512.

[0184] If the peer device does not confirm (for example, the peer device does not have the binding function, the binding times out, or the peer device is busy, or the user of the peer device does not agree to the binding), as Figure 5E shown in (a) of Figure 5E , mobile phone A can display a pop-up window 521, prompting the user "Device authentication failed". In response to the user clicking the "Got it" button 522, the pop-up window 521 can be hidden. Alternatively, the pop-up window 521 can be hidden after a preset time (for example, 3s). In another possible design, as Figure 5E shown in (b) of Figure 5E , mobile phone A can display a pop-up window 523, prompting the user "The peer is busy. Please initiate the binding later". In response to the user clicking the "Got it" button 524, the pop-up window 523 can be hidden. Alternatively, the pop-up window 523 can be hidden after a preset time (for example, 3s). In yet another possible design, as Figure 5E shown in (c) of Figure 5E , mobile phone A can display a pop-up window 525, prompting the user "The peer refuses to trust this device. Binding failed". In response to the user clicking the "Got it" button 526, the pop-up window 525 can be hidden. Alternatively, the pop-up window 525 can be hidden after a preset time (for example, 3s). Or, as Figure 5F shown, mobile phone A can display a pop-up window 527 in the interface 512, prompting the user "The peer's QR code is closed. Unable to complete device authentication. Binding failed". In response to the user clicking the "Got it" button 528, the pop-up window 527 can be hidden.

[0185] Assume the peer device is mobile phone B (for example, it can be HUAWEI P20). If mobile phone B receives a binding request from mobile phone A when displaying the desktop 530, as Figure 6A shown in (a) of Figure 6A , mobile phone B can display a pop-up window 531. The pop-up window 531 can include a prompt message 532 "HUAWEI MATE30 requests to bind to this device. Do you trust this device?" The pop-up window 531 can also include a "Don't trust" button 533 and a "Trust" button 534. The "Don't trust" button can also display a countdown (for example, 14s). When the countdown ends and the user does not click any button, the pop-up window 531 can be automatically hidden. In response to the user clicking the "Trust" button 534, mobile phone A can perform an authentication process with mobile phone B (refer to the relevant description of steps 718A - step 732 below), so that mobile phone A can bind to mobile phone B.

[0186] If mobile phone B receives a binding request from mobile phone A in the screen-off state or the locked-screen state, as Figure 6AAs shown in (b) therein, mobile phone B can display a pop-up window 536 on the lock screen interface 535. The pop-up window 536 can prompt the user that the intelligent collaboration application received a device binding request at 7:30 am. Specifically, it can be "HUAWEI MATE30 (i.e., mobile phone A) requests to bind to this device. Do you trust this device?" In response to the user's operation of entering the desktop from the locked screen state (e.g., entering a password or fingerprint), as Figure 6A As shown in (a) therein, the pop-up window 536 can be changed to the form of the pop-up window 531, and the user can choose to trust or not trust HUAWEI MATE30 (i.e., mobile phone A).

[0187] If mobile phone B receives a binding request from mobile phone A during video playback or game state, as Figure 6B As shown in (a) therein, mobile phone B can display a pop-up window 541 on the video interface or game interface 540. The pop-up window 541 can prompt the user that the intelligent collaboration application received a device binding request. Specifically, it can be "HUAWEI MATE30 requests to bind to this device. Do you trust this device?". In response to the user's operation of clicking the drop-down control 542, as Figure 6B As shown in (b) therein, the pop-up window 541 can display more information. For example, it can display a distrust button 543 and a trust button 544. A countdown (e.g., 14s) can also be displayed in the distrust button 543. When the countdown ends and the user does not click any button, the pop-up window 541 can be automatically hidden. In response to the user's operation of clicking the trust button 544, mobile phone A and mobile phone B can perform an authentication process (refer to the relevant description of steps 718A - 732 below).

[0188] In a possible design, in response to the user's operation of clicking the trust button, as Figure 6C As shown, mobile phone B can return to the desktop 530 and display a pop-up window 550. The pop-up window 550 can include a two-dimensional code 551 generated by mobile phone B, and can also include a prompt message 552 "Scan to bind. Allow HUAWEI MATE30 to scan and bind to this device". At this time, the user of mobile phone A can use mobile phone A to scan the two-dimensional code displayed on mobile phone B so that mobile phone A and mobile phone B can be bound. The pop-up window 550 can also include a cancel button 553. In response to the user's operation of clicking the cancel button 553, the pop-up window 550 can be hidden.

[0189] In some embodiments, if mobile phone A and mobile phone B log in to the same account (e.g., Huawei account), mobile phone A can directly bind to mobile phone B (e.g., as Figure 5C shown in (b), click the binding button corresponding to mobile phone B (HUAWEI P20) on mobile phone A), without waiting for mobile phone B to confirm (e.g., without waiting for the peer confirmation as Figure 5D shown in (a), nor as Figure 5D(scan the QR code displayed on the peer device as shown in (b)).

[0190] Taking mobile phone A and mobile phone B as examples, the specific implementation of the device-level authentication method provided in the embodiments of the present application will be described. Among them, mobile phone A and mobile phone B are devices with different accounts. As Figure 7A shown, it includes:

[0191] 701. The user triggers an operation to bind mobile phone B on mobile phone A.

[0192] For example, the user can click the binding button corresponding to mobile phone B on mobile phone A. For example, as Figure 5C shown in (b), in response to the user's operation of clicking the binding button 509 corresponding to mobile phone B (HUAWEI P20) on mobile phone A, mobile phone A executes step 702.

[0193] 702. The settings application of mobile phone A sends a binding request to the DM of mobile phone A.

[0194] Among them, the settings application refers to the application named "Settings". This settings application is used to configure the basic functions of mobile phone A. For example, it can be used for network configuration, display and brightness configuration, sound and vibration configuration, application management configuration, etc.

[0195] Among them, the information carried in the binding request may include the name of mobile phone A (for example, HUAWEI MATE30).

[0196] 703. Optionally, after receiving the binding request sent by the settings application of mobile phone A, the DM of mobile phone A requests the information of the authenticated devices from the device information database of mobile phone A.

[0197] The DM of mobile phone A can read the information of the authenticated devices from the device information database. The device information database stores the information of the devices that have been authenticated with mobile phone A. Among them, the information of the authenticated devices may include the device name and the device ID. The device ID may be, for example, the international mobile equipment identity (IMEI). Exemplarily, the information of the devices authenticated with mobile phone A may be as shown in Table 1.

[0198] Table 1

[0199]

[0200] 704. Optionally, the device information database of mobile phone A returns the information of the authenticated devices to the DM of mobile phone A.

[0201] In a possible design, when mobile phone A and mobile phone B authenticate each other, the information of the authenticated devices may include the information of mobile phone B.

[0202] It should be understood that steps 703 and 704 are optional when device-level authentication is performed between mobile phone A and mobile phone B. If steps 703 and 704 are executed, that is, if information of authenticated devices is obtained, mobile phone A can display the authenticated devices to the user. The authenticated devices can be in a default bound state, or the authenticated devices can be rebound.

[0203] Steps 703 and 704 are a schematic implementation for the DM of mobile phone A to obtain information of authenticated devices. The DM of mobile phone A can also obtain information of authenticated devices through other means (for example, reading information of authenticated devices from a preset storage space), and the present application does not make any limitations.

[0204] 705. The DM of mobile phone A requests information of nearby devices from the communication module of mobile phone A.

[0205] Device management can call the communication module of device A through a resident service to continuously send broadcasts to the surrounding area, so that device management can discover all near-field devices (that is, all devices under near-field communication, where near-field communication can include Wi-Fi communication, Bluetooth communication, etc.) by registering a broadcast listening service. Combining with the information of authenticated devices read from the device information database, the DM can classify and display the authenticated devices (such as kiki’s Mate pad, kiki’s Mate bookpro, etc. shown in (a) of Figure 5C and unauthenticated devices (such as the room TV, HUAWEI P20, Mate book X pro, etc. shown in (b) of Figure 5C in the form of icons among all near-field devices.

[0206] It should be noted that there is no necessary execution sequence between steps 703 and 705, and the present embodiment does not make specific limitations in this regard.

[0207] 706. The communication module of mobile phone A returns information of nearby devices to the DM of mobile phone A.

[0208] 707. The DM of mobile phone A pops up a list of nearby devices.

[0209] As Figure 5C shown in (b) of

[0210] 708. The user selects a device to be bound.

[0211] For example, asFigure 5C As shown in (b) of , the user can select the device to be bound from the nearby device list. For example, the user can select HUAWEI P20 (i.e., mobile phone B).

[0212] 709. The DM of mobile phone A requests the communication module of mobile phone A to create a lower-level channel.

[0213] The lower-level channel can be a Bluetooth channel, a Wi-Fi channel, etc., and this application does not make a limitation.

[0214] 710. The communication module of mobile phone A interacts with the communication module of mobile phone B to create a lower-level channel.

[0215] 711. Optionally, the communication module of mobile phone A sends a creation success notification to the DM of mobile phone A.

[0216] That is, the communication module of mobile phone A sends a lower-level channel creation success notification to the DM of mobile phone A, indicating that the lower-level channel has been successfully created between the communication module of mobile phone A and the communication module of mobile phone B.

[0217] It should be understood that when device-level authentication is performed between mobile phone A and mobile phone B, step 711 is optional. If step 711 is executed, the DM of mobile phone A can subsequently learn in a timely manner that the lower-level channel has been successfully created, so that data can be transmitted through the lower-level channel subsequently. Or, it can also be learned that the lower-level channel has been successfully created based on other methods. For example, if no notification of lower-level channel creation failure is received after a preset time, it can be considered that the lower-level channel has been successfully created.

[0218] 712. The DM of mobile phone A sends an authentication request message to mobile phone B through the communication module of mobile phone A.

[0219] Among them, the authentication request message may include the identifier of mobile phone A (for example, name or ID) and the identity authentication information generated by mobile phone A. The identity authentication information generated by mobile phone A may include a token generated by mobile phone A. The name of mobile phone A may be, for example, HUAWEI MATE30. The token may be, for example, a random string of several digits.

[0220] Among them, the token can be used for identity authentication. In the embodiments of this application, mobile phone A can send a token to mobile phone B. The token can be the device number / device mac address of mobile phone A, or other identifier used to determine mobile phone A. When mobile phone B receives the token of mobile phone A, it can add the information of the token to the two-dimensional code picture generated by mobile phone B subsequently, so that the two-dimensional code picture can only be used by mobile phone A.

[0221] As Figure 7B shown, the above method further includes:

[0222] 713. Optionally, the communication module of mobile phone B sends a creation success notification to the DM of mobile phone B.

[0223] That is, the communication module of mobile phone B sends a notification of successful creation of the underlying channel to the DM of mobile phone B, indicating that the underlying channel has been successfully created between the communication module of mobile phone B and the communication module of mobile phone A.

[0224] It should be understood that step 713 is optional when device-level authentication is performed between mobile phone A and mobile phone B. If step 713 is executed, the DM of mobile phone B can subsequently learn in a timely manner that the underlying channel has been successfully created, so that data can be transmitted through the underlying channel subsequently. Alternatively, it is also possible to learn that the underlying channel has been successfully created based on other methods. For example, if no notification of failed creation of the underlying channel is received after a preset time, it can be considered that the underlying channel has been successfully created.

[0225] It should be noted that there is no necessary execution sequence between step 711 and step 713, and this embodiment does not make specific limitations in this regard.

[0226] 714. The communication module of mobile phone A sends an authentication request message to the communication module of mobile phone B.

[0227] The communication module of mobile phone A can send an authentication request message to the communication module of mobile phone B through the underlying channel.

[0228] 715. The communication module of mobile phone B forwards the authentication request message to the DM of mobile phone B.

[0229] It can be understood that steps 712, 714, and 715 are used to describe the process of mobile phone A sending an authentication request message to mobile phone B. The DM of mobile phone A and the DM of mobile phone B need to communicate through the communication module of mobile phone A and the communication module of mobile phone B respectively. Of course, the DM of mobile phone A and the DM of mobile phone B can also communicate through other modules, or the DM of mobile phone A and the DM of mobile phone B can have the communication ability to directly communicate. This application does not make limitations in this regard.

[0230] 716. Optionally, the DM of mobile phone B notifies the user through a pop-up window whether to agree to bind.

[0231] Exemplarily, as shown in (a) of Figure 6A , mobile phone A can pop up a pop-up window 531. The pop-up window 531 may include a prompt message 532 "HUAWEI MATE30 requests to bind this device. Do you trust this device?", and the pop-up window 531 may also include a distrust button 533 and a trust button 534.

[0232] 717. Optionally, mobile phone B receives the user's operation of agreeing to bind.

[0233] For example, asFigure 6A As shown in (a) of , when the user clicks the trust button 534, it can indicate that the user agrees to bind.

[0234] If the user agrees (for example, as shown in (a) of , if the user clicks the trust button 534), the DM of mobile phone B can return the information that the user agrees to the DM of mobile phone A through the communication module. Mobile phone A can prompt the user to actively scan the QR code (QR code picture) displayed by the peer (mobile phone B). Figure 6A

[0235] Figure 5E In addition, if the user does not agree (for example, if the user clicks the distrust button 533), the DM of mobile phone B can return the information that the user does not agree to the DM of mobile phone A through the communication module. Mobile phone A can display the prompt message as shown in (c) of , and the binding fails.

[0236]

[0237] It should be understood that when device-level authentication is performed between mobile phone A and mobile phone B, steps 716 and 717 can be optional. For example, if mobile phone A and mobile phone B log in to the same account, or set services such as family numbers, mobile phone B can directly execute step 718A and its subsequent necessary steps without asking the user whether to agree to bind.

[0238] Steps 716 and 717 are an implementation manner for mobile phone B to prompt the user whether to agree to bind. Mobile phone B can also prompt the user in other ways, such as through background system notification messages. This application does not make any limitations.

[0239] 718A. The DM of mobile phone B determines whether a group related to mobile phone A has been established on mobile phone B.

[0239] The DM of mobile phone B can query from the HiChain of mobile phone B whether a public group related to mobile phone A has been established. Among them, the HiChain of mobile phone B can store all group information established by mobile phone B, including public groups and private groups. Among them, a public group can refer to a group established at the device granularity. For example, two devices belonging to a public group means that the two devices have passed device-level authentication, and all applications between the two devices can communicate securely. A private group is a group established at the device and application granularity. For example, the first application of the first device can perform application-level authentication with the second application of the second device. After passing the application-level authentication, the first application and the second application belong to a private group. At this time, the first application and the second application can communicate securely (for example, they can securely share data). The identifiers of the first application and the second application can be the same or different, and this application does not limit this. Two applications respectively corresponding to two devices belonging to a private group means that the two devices have passed application-level authentication, and specific applications respectively corresponding to the two devices can communicate securely. Exemplarily, all group information established by mobile phone B can be shown in Table 2:

[0240] Table 2

[0241]

[0242] Optionally, Group 1 and Group 2 in Table 2 can be combined into a group including 3 members, such as Group 5 (mobile phone B, mobile phone C, mobile phone D). In this way, mobile phone A can find the device that has passed device-level authentication with mobile phone A from Group 5, without having to traverse the public groups established between every two devices.

[0243] Optionally, Group 3 and Group 4 in Table 2 can be combined into a group including 3 members, such as Group 6 (Application 1 of mobile phone B, Application 2 of mobile phone D, Application 3 of mobile phone E). In this way, mobile phone A can find the applications of the devices that have passed application-level authentication with mobile phone A from Group 6, without having to traverse the private groups established between every two applications.

[0244] 718B. If mobile phone B has not established a group related to mobile phone A, the DM of mobile phone B requests the security management module of mobile phone B to create a group.

[0245] The security module of mobile phone B creates a group regarding mobile phone A, and the group name is the device IDs of mobile phone A and mobile phone B. Further, the group attribute between mobile phone A and mobile phone B can be set to public, that is, all applications between mobile phone A and mobile phone B can communicate with each other.

[0246] 718C. The security management module of mobile phone B sends a group creation success notification to the DM of mobile phone B.

[0247] It should be understood that steps 718B and 718C are a schematic way to create a group. This application does not limit other ways to create a group. For example, the DM of mobile phone B can directly create a group.

[0248] 719. The DM of mobile phone B requests a label from the HarmonyOS label management module of mobile phone B.

[0249] The HarmonyOS label management module of mobile phone B can generate a label, which includes authentication verification information and the session identifier of mobile phone B. The authentication verification information can include the token received from mobile phone A. Or, it can be considered that the authentication verification information includes the token received from mobile phone A and the session identifier of mobile phone B. The session identifier of mobile phone B includes the device connection information of mobile phone B. For example, the session identifier of mobile phone B includes the Wi-Fi address of mobile phone B (e.g., IP address and port number) or the Bluetooth address.

[0250] The authentication verification information can also include the personal identification number PIN corresponding to the group. The PIN can be, for example, several random digits, such as 6 - digit or 8 - digit random digits, etc. In the embodiments of this application, mobile phone B can send the PIN corresponding to the group to mobile phone A. When mobile phone A needs to join the group created by mobile phone B, it can carry the PIN corresponding to the group in the request. When mobile phone B determines that the PIN carried by mobile phone A is correct (i.e., the PIN sent by mobile phone B to mobile phone A), it considers mobile phone A to be safe and trustworthy and allows mobile phone A to join the group created by mobile phone B.

[0251] 720. The HarmonyOS label management module of mobile phone B requests a QR code picture (BitMap) of the authentication verification information from the QR code recognition module of mobile phone B.

[0252] The QR code recognition module of mobile phone B can assemble a QR code picture according to the authentication verification information. It should be noted that in the above embodiments, the QR code picture is used as an identifier for illustration, and the QR code picture can be replaced by other types of identifiers, such as barcodes, strings, etc. This application does not make a limitation.

[0253] 721. The QR code recognition module of mobile phone B returns the QR code picture to the HarmonyOS label management module of mobile phone B.

[0254] 722. The HarmonyOS label management module of mobile phone B returns the QR code picture to the DM of mobile phone B.

[0255] 723a. Optionally, the DM of mobile phone B sends the QR code picture to the communication module of mobile phone B.

[0256] In a possible design, the DM of mobile phone B can send the QR code picture of mobile phone B to mobile phone A through the communication module of mobile phone B, so that mobile phone A can perform an internal scan on the QR code picture. That is, after step 723a, steps 723b - 725 can be executed. In another possible design, mobile phone B can display the QR code picture of mobile phone B on the display interface of mobile phone B (such as the display interface Figure 6C shown), so that mobile phone A can directly scan it, so that the QR code recognition module in mobile phone A can directly obtain the QR code picture generated by mobile phone B, thus skipping steps 723b - 725. The above two designs can both achieve the technical effects of this solution, and this application does not limit this.

[0257] 723b. Optionally, the communication module of mobile phone B sends the QR code picture to the communication module of mobile phone A. <l

[0258] The DM of mobile phone A can launch the QR code recognition module and scan the QR code picture generated by mobile phone B through the QR code recognition module.

[0259] As Figure 7C shown, the above method further includes:

[0260] 724. Optionally, the communication module of mobile phone A sends the QR code picture to the DM of mobile phone A.

[0261] 725. Optionally, the DM of mobile phone A sends the QR code picture to the QR code recognition module of mobile phone A.

[0262] 726. The QR code recognition module of mobile phone A scans the QR code picture and sends the recognized information to the HarmonyOS label management module of mobile phone A.

[0263] 727. The HarmonyOS label management module of mobile phone A parses the information sent by the QR code recognition module to obtain a parsing result.

[0264] Among them, the parsing result may include information such as token, PIN, and the session identifier of mobile phone B.

[0265] 728. The HarmonyOS label management module of mobile phone A sends the parsing result to the DM of mobile phone A.

[0266] It can be understood that steps 724 - 728 are a schematic implementation method for mobile phone A to process the QR code picture. Mobile phone A can also process the QR code picture in other ways, and this application does not limit this. For example, the DM of mobile phone A can integrate the QR code picture processing function, so that the DM of mobile phone A can directly scan and parse the QR code picture to obtain information such as token, PIN, and the session identifier of mobile phone B.

[0267] 729. The DM of mobile phone A verifies the token.

[0268] If the token received from mobile phone B is the same as the token carried in the authentication request message, perform step 730.

[0269] 730. The DM callback authentication of mobile phone A is successful.

[0270] It should be understood that steps 729 and 730 are optional when mobile phone A and mobile phone B perform device-level authentication. If steps 729 and 730 are executed, that is, if the DM of mobile phone A verifies the token, the security of the communication between mobile phone A and mobile phone B can be better guaranteed.

[0271] 731. Mobile phone A joins the public group created by mobile phone B.

[0272] The DM of mobile phone A determines the Wi-Fi address or Bluetooth address of mobile phone B according to the session identifier, and applies to the security module of mobile phone A to join the group created by mobile phone B.

[0273] The security module of mobile phone A creates an underlying communication channel using the Wi-Fi address or Bluetooth address, and sends a group join request to mobile phone B. The group join request may include the group ID. Optionally, the group join request may also include a PIN. After receiving the group join request, mobile phone B can verify the PIN. After the authentication passes (that is, the PIN is the same as the PIN in the QR code picture), the two devices join the same group (the group members of this group may include mobile phone A and mobile phone B, and the attribute of this group is public), and the authentication is completed.

[0274] In a possible implementation, when mobile phone B receives the group join request and the authentication passes, it will send a response message to mobile phone A, and this response message indicates that mobile phone A has joined the public group created by mobile phone B.

[0275] 732. The security management module of mobile phone A notifies the application program (settings application) that the authentication is successful.

[0276] Mobile phone A can locally save the information of the group. The information of the group can be the group members (the group members of this group may include mobile phone A and mobile phone B), and the information of the group can also include the group name and attribute information of the group (for example, the attribute is public).

[0277] In this way, the device-level authentication between mobile phone A and mobile phone B is completed, and all applications between mobile phone A and mobile phone B can be interoperable. For example, the live broadcast application, KTV application, shopping application and email application of mobile phone A can be interoperable with the live broadcast application, KTV application, shopping application and email application of mobile phone B.

[0278] In some embodiments, if one of mobile phone A and mobile phone B is logged in with an account (e.g., a Huawei account) and the other is not, mobile phone A and mobile phone B can perform all or part of steps 701 to 732 above to perform verification (i.e., device-level authentication) when mobile phone A and mobile phone B are bound, thereby ensuring the security of data between the devices.

[0279] In some embodiments, if neither phone A nor phone B has a login account (e.g., a Huawei account), phone A and phone B can perform steps 701 to 732 above to perform verification when phone A and phone B are bound, thereby ensuring the security of data between the devices.

[0280] In some embodiments, if mobile phone A and mobile phone B are logged into the same account (e.g., Huawei account), mobile phone A and mobile phone B can perform steps 701 to 732 above to verify when mobile phone A and mobile phone B are bound, further ensuring the security of data between devices.

[0281] It should be noted that some of the steps in steps 701 to 732 above may be optional, that is, they are not necessary technical features of the device-level authentication solution. For example, steps 703 and 704 may be optional steps, that is, you can directly check the surrounding devices without querying the authenticated devices. For another example, steps 711 and 713 may be optional steps, that is, you do not need to send a successful creation notification. For another example, steps 716 and 717 may be optional steps, that is, you can directly bind without the user's consent. For another example, steps 723b to 725 may be optional steps, in which case mobile phone A can directly obtain the QR code image generated by mobile phone B (for example, by scanning the QR code image displayed by mobile phone B).

[0282] If device-level authentication is not performed between devices, applications between devices can be authenticated at the application level, so that specific applications can communicate with each other. The following describes the UI interface for application-level authentication provided by the embodiment of the present application, taking the live broadcast application as an example, in conjunction with specific scenarios.

[0283] With the development of e-commerce, more and more people are interested in livestreaming as a new sales channel. Livestreaming not only requires clear footage and accurate audio capture, but also a superior interactive experience. A current pain point in livestreaming is the inability to simultaneously display the host and product details in the same shot, reducing the sense of authenticity and identity for e-commerce show directors.

[0284] This application provides a distributed display solution based on cross-device FA sharing for live broadcast services. For example, the live broadcast screen of mobile phone A (the live broadcast screen of device A can be regarded as an FA, such as FA1) can be shared to mobile phone B, and mobile phone B can simultaneously display the FA of mobile phone A and the live broadcast screen of mobile phone B (the live broadcast screen of device B can be regarded as an FA, such as FA2), achieving the experience of cross-device display of one or more FAs, eliminating the cumbersome process of users switching terminals back and forth, and greatly reducing user operations. This application does not require the devices to meet the requirement of the same system, nor does it require the devices to log in to the same device account (for example, the same Huawei account), and has a wide range of applications.

[0285] Exemplarily, as Figure 8A shown, after the user opens the live broadcast application on mobile phone A, mobile phone A can display the live broadcast interface 801, and the live broadcast interface 801 may include a migration button 802, and the migration button 802 is located in the upper left corner of the interface 801. It should be understood that the migration button 802 may also be located in the lower left corner, lower right corner, upper right corner, etc. of the interface 801, and this application does not make a limitation. Of course, the text displayed on the button 802 may also be other content, such as sharing, transferring, etc., and this application does not make a limitation. In response to the user's operation of clicking the migration button 802 on the live broadcast interface 801 (the migration button 802 is used to migrate (send) the live broadcast interface of mobile phone A to other devices (for example, mobile phone B)), as Figure 8B shown in (a) of, mobile phone A can pop up a dialog box 803. It should be understood that the embodiment of this application does not limit the jump method between UI interfaces. For example, as Figure 8A shown, in response to the user's operation of a specific gesture (such as three-finger swipe down, knuckle tap, etc.), as Figure 8B shown in (a) of, the mobile phone can display the dialog box 803. Among them, the dialog box 803 may include nearby devices, and the nearby devices include authenticated devices (bedroom TV, monica’s Mate pad, etc.) and unauthenticated devices (room TV, HUAWEI P20, and Mate book X pro, etc.). In response to the user's operation of clicking the control 804 corresponding to HUAWEI P20 (an unauthenticated device), mobile phone A can send an authentication request message to mobile phone B. And, as Figure 8B shown in (b) of, a prompt message 805 "Waiting for confirmation from the other end" can be displayed below HUAWEI P20. As Figure 8C shown in (a) of, if mobile phone B (HUAWEI P20) receives the authentication request message sent by mobile phone A when displaying the live broadcast interface 811, mobile phone B can display a dialog box 812, and the dialog box 812 includes a prompt message "HUAWEIMATE30 (mobile phone A) requests to migrate the live broadcast interface to this machine. Do you agree?", in response to the user's operation of clicking the drop-down button 813, asFigure 8C As shown in (b) of , the pop-up window 812 can display more content, such as a disagree button 814 and an agree button 815a. Optionally, in response to the user clicking the agree button 815a, as Figure 8C shown in (c) of , the mobile phone can display a pop-up window 815b, which can include an only-this-time agree button 815c and an always-agree (no more prompts in the future) button 815d. In response to the user clicking the agree button 815a or the only-this-time agree button 815c or the always-agree button 815d, as ​ shown, the mobile phone B can display a pop-up window 816, which can include a QR code picture generated by the mobile phone B and a prompt message 817 "Scan the code for authentication, allow HUAWEI MATE30 to scan the code for authentication". At this time, the user of the mobile phone A can scan the QR code picture shown on the mobile phone B, and then, the mobile phone B can receive the live video stream (FA1) from the mobile phone A, as ​ shown, the mobile phone B can display the live video interface 819 sent by the mobile phone A on the live video interface 811. Or, in response to the user clicking the agree button 815, the mobile phone B can receive the live video stream (FA1) from the mobile phone A, as ​ shown, the mobile phone B can display the live video interface 819 sent by the mobile phone A on the live video interface 811.

[0286] Taking the live video application as an example, the specific implementation manner of the application-level authentication method provided by the embodiments of the present application will be described below. The method provided by the embodiments of the present application can be applied to two near-field devices, such as the mobile phone A and the mobile phone B. The mobile phone A and the mobile phone B are devices with different accounts (for example, not logged in to the same Huawei account), and both the mobile phone A and the mobile phone B have the live video application opened. As ​ shown, it includes:

[0287] 901. The mobile phone A receives an operation triggered by the user to migrate the function.

[0288] For example, as ​ shown, when the user is live streaming the host on the mobile phone A, the user can click the migration button 802. The migration button can also be called a sharing button, a sending button, etc., which is not limited in the present application.

[0289] The user can trigger the function migration in other ways. For example, the user can trigger the function migration by "touch and hold" or "scan the code", which is not limited in the present application.

[0290] 902. The application program (for example, the live video application) sends a migration request to the DM of the mobile phone A.

[0291] Among them, the information carried in the migration request may include the identifier of the application on the initiating end (the local live application package name), the identifier of the application on the receiving end (the remote live application package name), and the name of mobile phone A. Among them, the receiving-end package name may be given by the application (for example, the live application), depending on the design of the application by the application vendor, which will not be elaborated here.

[0292] In a possible design, the information carried in the migration request may be arranged according to a preset order. For example, the preset order may be the name of mobile phone A, the identifier of the application on the initiating end, and the identifier of the application on the receiving end in sequence. Or, the preset order may be the identifier of the application on the initiating end, the identifier of the application on the receiving end, and the name of mobile phone A in sequence.

[0293] 903. Optionally, after receiving the migration request, the DM of mobile phone A requests the authenticated devices from the device information database of mobile phone A.

[0294] For the specific process, reference can be made to the relevant description in step 703, which will not be elaborated here.

[0295] 904. Optionally, the device information database of mobile phone A returns the information of the authenticated devices to the DM of mobile phone A.

[0296] It should be understood that steps 903 and 904 are optional when mobile phone A and mobile phone B perform device-level authentication. If steps 903 and 904 are executed, that is, if the information of the authenticated devices is obtained, mobile phone A can display the authenticated devices to the user.

[0297] Steps 903 and 904 are a schematic implementation method for the DM of mobile phone A to obtain the information of the authenticated devices. The DM of mobile phone A can also obtain the information of the authenticated devices through other means (for example, reading the information of the authenticated devices from a preset storage space), which is not limited in this application.

[0298] 905. The DM of mobile phone A requests the information of nearby devices from the communication module of mobile phone A.

[0299] For the specific process, reference can be made to the relevant description in step 705, which will not be elaborated here.

[0300] 906. The communication module of mobile phone A returns the information of nearby devices to the DM of mobile phone A.

[0301] 907. The DM of mobile phone A pops up a list of nearby devices.

[0302] The list of nearby devices may be, for example, the pop-up window 803 shown in (a) of ​

[0303] The user can select a device from the list of nearby devices. If it is an untrusted device (i.e., a device with a different account that has not been authenticated (for example, not logged in to the same Huawei account)), after step 907, steps 908 - 936 can be executed for application-level authentication. If it is a trusted device (for example, logged in to the same Huawei account, or has been authenticated before (including device-level authentication or application-level authentication)), then the FA can be directly migrated, that is, after step 907, steps 933 - 936 can be directly executed.

[0304] 908. The user selects an unauthenticated device.

[0305] For example, as shown in (a) of ​ , the user selects HUAWEI P20, and HUAWEI P20 is an untrusted device.

[0306] 909. The DM of mobile phone A requests the communication module of mobile phone A to create a low-level channel.

[0307] The low-level channel can be a Bluetooth channel or a Wi-Fi channel, etc., which is not limited in this application.

[0308] 910. The communication module of mobile phone A interacts with the communication module of mobile phone B to create a low-level channel.

[0309] 911. Optionally, the communication module of mobile phone A sends a low-level channel creation success notification to the DM of mobile phone A.

[0310] It should be understood that when mobile phone A and mobile phone B perform device-level authentication, step 911 is optional. If step 911 is executed, the DM of mobile phone A can subsequently learn in a timely manner that the low-level channel has been successfully created, so that data can be transmitted through the low-level channel subsequently. Or, it can also learn that the low-level channel has been successfully created based on other methods. For example, if no low-level channel creation failure notification is received after a preset time, it can be considered that the low-level channel has been successfully created.

[0311] 912. The DM of mobile phone A sends an authentication request message to mobile phone B through the communication module of mobile phone A.

[0312] Among them, the authentication request message includes the name of the initiating device (for example, HUAWEI MATE30), the package name of the initiating end (for example, com.zhibo.video), and the package name of the receiving end (for example, com.zhibo.video). The authentication request message also includes the token generated by mobile phone A.

[0313] As shown in ​ , the above method further includes:

[0314] 913. Optionally, the communication module of mobile phone B sends a low-level channel creation success notification to the DM of mobile phone B.

[0315] It should be noted that there is no necessary execution order between step 911 and step 913, and this embodiment does not make specific limitations in this regard.

[0316] It should be understood that when device-level authentication is performed between mobile phone A and mobile phone B, step 913 is optional. If step 913 is executed, the DM of the subsequent mobile phone B can timely learn that the underlying channel is successfully created, so that data can be transmitted through the underlying channel subsequently. Or, it is also possible to learn that the underlying channel is successfully created based on other methods. For example, if no notification of the failure to create the underlying channel is received after a preset time, it can be considered that the underlying channel is successfully created.

[0317] 914. The communication module of mobile phone A sends an authentication request message to the communication module of mobile phone B.

[0318] The information carried in the authentication request message may include the identifier of the application program at the initiating end, the identifier of the application program at the terminating end, and the name of mobile phone A.

[0319] In a possible design, the information carried in the authentication request message may be arranged according to a preset order. For example, the preset order may be the name of mobile phone A, the identifier of the application program at the initiating end, and the identifier of the application program at the terminating end in sequence. Or, the preset order may be the identifier of the application program at the initiating end, the identifier of the application program at the terminating end, and the name of mobile phone A in sequence.

[0320] 915. The communication module of mobile phone B forwards the authentication request message to the DM of mobile phone B.

[0321] It can be understood that steps 912, 914, and 9!5 are used to describe the process of mobile phone A sending an authentication request message to mobile phone B. The DM of mobile phone A and the DM of mobile phone B need to communicate through the communication module of mobile phone A and the communication module of mobile phone B respectively. Of course, the DM of mobile phone A and the DM of mobile phone B can also communicate through other modules, or the DM of mobile phone A and the DM of mobile phone B can have the communication ability to directly communicate. This application does not make limitations.

[0322] 916. Optionally, the DM of mobile phone B notifies the user through a pop-up window whether to agree to the migration.

[0323] Exemplarily, as shown in (a) of ​ When mobile phone B receives the authentication request message sent by mobile phone A while displaying the live broadcast interface 811, mobile phone B can display a pop-up window 812. The pop-up window 812 includes a prompt message "HUAWEI MATE30 requests to migrate the live broadcast interface to this device. Do you agree?". In response to the user's operation of clicking the drop-down button 813, as shown in ​As shown in (b) thereof, the pop-up window 812 can display more content, such as a disagree button 814 and an agree button 815a.

[0324] Optionally, in response to the user clicking the agree button 815a, as ​ shown in (c) thereof, the mobile phone can display a pop-up window 815b, which can include an only-this-time agree button 815c and an always-agree (no more prompts in the future) button 815d. It should be understood that in response to the user clicking the only-this-time agree button 815c, after performing the following steps 917 - step 932, the mobile phone A can migrate the live interface (i.e., FA1) to the mobile phone B once. When migrating FA from the live application of the mobile phone A to the live application of the mobile phone B next time, re-authentication is required. For example, steps 901 - step 932 can be re-executed. In response to the user clicking the always-agree button 815d, after performing the following steps 917 - step 932, the live application of the mobile phone A can always migrate FA to the live application of the mobile phone B without re-authentication (for example, without re-executing steps 901 - step 932).

[0325] 917. Optionally, the mobile phone B receives the user's operation of agreeing to migrate.

[0326] Exemplarily, as ​ shown in (b) thereof, the mobile phone B can receive the user's operation of clicking the agree button 815a.

[0327] If the user agrees (for example, if the user clicks the agree button 815a), the DM of the mobile phone B can return the user's agreement information to the DM of the mobile phone A through the communication module, and the mobile phone A can prompt the user to actively scan the QR code (QR code picture) displayed by the peer (mobile phone B).

[0328] In addition, if the user disagrees (for example, if the user clicks the disagree button 814), the DM of the mobile phone B can return the user's disagreement information to the DM of the mobile phone A through the communication module, and the mobile phone A can display the prompt information shown in (c) thereof, and the migration fails. ​

[0329] It should be understood that when performing device-level authentication between the mobile phone A and the mobile phone B, steps 916 and 917 can be optional. For example, if the mobile phone A and the mobile phone B log in to the same account, or set services such as family numbers, the mobile phone B can directly execute step 918A and the subsequent necessary steps without asking the user whether to agree to migrate.

[0330] Steps 916 and 917 are one implementation way for the mobile phone B to prompt the user whether to agree to migrate. The mobile phone B can also prompt the user in other ways, such as through a background system notification message, which is not limited in this application. ​

[0331] The DM of mobile phone B determines whether mobile phone B has established a group related to the live application of mobile phone A.

[0332] The DM of mobile phone B can query from the HiChain of mobile phone B whether mobile phone B has established a private group related to mobile phone A. For relevant descriptions, please refer to step 718A and will not be elaborated here.

[0333] 918B. If mobile phone B has not established a group related to the live application of mobile phone A, the DM of mobile phone B requests the security management module of mobile phone B to create a group.

[0334] The security module of mobile phone B can create a group for the live application of mobile phone A (the group members of this group can include the live application of mobile phone A and the live application of mobile phone B). Further, the group attribute can be set to private, that is, it is only applicable to specific applications (live applications).

[0335] Optionally, mobile phone B can send the group ID of the group it created for the live application of mobile phone A to mobile phone A. Mobile phone A can join the group created by mobile phone B according to the group ID. Optionally, mobile phone B can also send the device ID of mobile phone B to mobile phone A. The device ID of mobile phone B can be used when mobile phone A communicates with mobile phone B. The device ID of mobile phone B can include the network ID (netId) and the device IP (deviceIP).

[0336] 918C. The security management module of mobile phone B sends a group creation success notification to the DM of mobile phone B.

[0337] It should be understood that steps 918B and 918C are a schematic way of creating a group. This application does not limit other ways of creating a group. For example, the DM of mobile phone B can directly create a group.

[0338] 919. The DM of mobile phone B requests a label from the HarmonyOS label management module of mobile phone B.

[0339] The HarmonyOS label management module of mobile phone B can generate a label, which includes authentication verification information. The authentication verification information can include the token received from mobile phone A and information such as the session identifier of mobile phone B. The session identifier of mobile phone B includes the device connection information of mobile phone B. For example, the session identifier of mobile phone B includes the Wi-Fi address of mobile phone B (for example, IP address and port number) or the Bluetooth address. The authentication verification information can also include the PIN corresponding to the group.

[0340] 920. The HarmonyOS label management module of mobile phone B requests a QR code picture of the authentication verification information from the QR code recognition module of mobile phone B.

[0341] The QR code recognition module of mobile phone B can assemble a QR code picture according to the authentication verification information.

[0342] 921. The QR code recognition module of mobile phone B returns the QR code picture to the HarmonyOS label management module of mobile phone B.

[0343] 922. The HarmonyOS label management module of mobile phone B returns the QR code picture to the DM of mobile phone B.

[0344] 923a. Optionally, the DM of mobile phone B sends the QR code picture to the communication module of mobile phone B.

[0345] In a possible design, the DM of mobile phone B can send the QR code picture of mobile phone B to mobile phone A so that mobile phone A can perform an internal scan on the QR code picture. That is, after step 923a, steps 923b - 925 can be executed. In another possible design, mobile phone B can display the QR code picture of mobile phone B on the display interface of mobile phone B (such as ​ the display interface shown), so that mobile phone A can directly scan it, so that the QR code recognition module in mobile phone A can directly obtain the QR code picture generated by mobile phone B, thus skipping steps 923b - 925. The above two designs can both achieve the technical effects of this solution, and this application does not limit this.

[0346] 923b. Optionally, the communication module of mobile phone B sends the QR code picture to the communication module of mobile phone A.

[0347] The DM of mobile phone A can launch the QR code recognition module to scan the QR code picture generated by mobile phone B through the QR code recognition module.

[0348] As ​ shown, the above method further includes:

[0349] 924. Optionally, the communication module of mobile phone A sends the QR code picture to the DM of mobile phone A.

[0350] 925. Optionally, the DM of mobile phone A sends the QR code picture to the QR code recognition module of mobile phone A.

[0351] 926. The QR code recognition module of mobile phone A scans the QR code and sends the recognized information to the HarmonyOS label management module of mobile phone A.

[0352] 927. The HarmonyOS label management module of mobile phone A analyzes the information sent by the QR code recognition module to obtain an analysis result.

[0353] Among them, the analysis result may include information such as the token, PIN of mobile phone B, and the session identifier of mobile phone B.

[0354] 928. The HarmonyOS label management module of mobile phone A sends the parsing result to the DM of mobile phone A.

[0355] It can be understood that steps 924 - 928 are a schematic implementation method for mobile phone A to process the QR code picture. Mobile phone A can also process the QR code picture in other ways, which is not limited in this application. For example, the DM of mobile phone A can integrate the QR code picture processing function, so that the DM of mobile phone A can directly scan and parse the QR code picture to obtain information such as token, PIN, and the session identifier of mobile phone B.

[0356] 929. The DM of mobile phone A verifies the token.

[0357] If the token received from mobile phone B is the same as the token carried in the authentication request message, execute step 930.

[0358] 930. The DM of mobile phone A calls back to indicate successful authentication.

[0359] It should be understood that steps 929 and 930 are optional when mobile phone A and mobile phone B perform device-level authentication. If steps 929 and 930 are executed, that is, if the DM of mobile phone A verifies the token, it can better ensure the security of the communication between mobile phone A and mobile phone B.

[0360] 931. The live application of mobile phone A joins the private group created by mobile phone B.

[0361] The DM of mobile phone A indexes the Wi-Fi address or Bluetooth address of the peer device (i.e., mobile phone B) saved locally according to the session identifier, and applies to the security module of mobile phone A to join the private group created by mobile phone B.

[0362] The security module of mobile phone A creates an underlying communication channel using the Wi-Fi address or Bluetooth address, and sends a group join request to mobile phone B. The group join request includes the parsed PIN and group ID. After receiving the group join request, mobile phone B verifies the PIN. After successful authentication (i.e., the PIN is the same as the PIN in the QR code picture), the live applications on both devices join the same group (the group members of this group can include the live applications of mobile phone A and mobile phone B, and the attribute of this group is private), and the authentication is completed.

[0363] In a possible implementation, when mobile phone B receives the group join request and the authentication is successful, it will send a response message to mobile phone A, indicating that the live application of mobile phone A has joined the private group created by mobile phone B.

[0364] 932. The security management module of mobile phone A notifies the live application that the authentication is successful.

[0365] In this way, application-level authentication is completed between the live broadcast applications of mobile phone A and mobile phone B, and the live broadcast applications between mobile phone A and mobile phone B can communicate with each other.

[0366] 933. The live broadcast application of mobile phone A requests the DEF of mobile phone A to migrate FA1.

[0367] Among them, FA1 can implement all or part of the functions in the live broadcast application, and it consists of one or more user interfaces.

[0368] 934. The DEF of mobile phone A sends the service information of FA1 to the DMS of mobile phone B.

[0369] The service information of FA1 may include the live video stream, audio stream, bullet screen information, etc.

[0370] 935. The DMS of mobile phone B requests the DEF of mobile phone B to continue FA1.

[0371] Among them, the DEF of mobile phone B continuing FA1 means that the DEF of mobile phone B processes and displays FA1 according to the received service information. Among them, the display content of FA1 on mobile phone B may be synchronized with the display content of FA1 on mobile phone A, or there may be differences in format or partial content from the display content of FA1 on mobile phone A. This application does not limit this.

[0372] 936. The DEF of mobile phone B pulls up and displays FA1.

[0373] Among them, the DEF of mobile phone B pulling up FA1 means that the DEF of mobile phone B runs and displays FA1.

[0374] If mobile phone B is currently in the live broadcast screen (i.e., running FA2), the DEF of mobile phone B can detect FA2 of mobile phone B. If FA2 has the ability to display FA1 (i.e., FA2 supports displaying multiple FAs), the DEF can pull up and display the live FA1 on FA2, that is, display the FA1 interface on the FA2 interface. For example, as ​ shown, mobile phone B can display the live broadcast interface 819 sent by mobile phone A on the live broadcast interface 811. In this way, users can view the live broadcast screen of mobile phone B and the live broadcast screen of mobile phone A on mobile phone B at the same time, achieving the experience of cross-device displaying one or more FAs, saving the trouble of users switching terminals back and forth, simplifying user operations, and improving user experience.

[0375] If mobile phone B is currently in the live broadcast screen (i.e., running FA2), but FA2 does not have the ability to display FA1, then the migration of FA1 fails, but mobile phone A can still continue to share other FAs of the live broadcast application (for example, the live shopping cart FA3) without establishing a connection again.

[0376] If mobile phone B is currently on the desktop interface, the FA1 of mobile phone A can be previewed and controlled on the desktop.

[0377] It should be understood that if there is a mobile phone C migrating the FA on mobile phone C (for example, FA4) to mobile phone B, and mobile phone B is currently on the FA2 display interface, if FA2 has the ability to display multiple FAs, mobile phone B can display 3 FAs (FA1, FA2, and FA3) simultaneously, and so on.

[0378] The embodiments of the present application are mainly applied to the scenario of sharing FAs between live broadcast applications across devices, that is, through the sharing of FAs among multiple devices, enabling a certain device to display multiple FAs simultaneously. In this way, dual - perspective dual - screen live broadcasts can be freely carried out, which can be used in scenarios such as evaluation live broadcasts (unboxing close - up + host), sports live broadcasts (athlete's perspective + commentator), education live broadcasts (book close - up + teacher), and e - commerce live broadcasts (product details + show host), etc., and can improve the user experience and product competitiveness.

[0379] In some embodiments, if one of mobile phone A and mobile phone B logs in to an account (for example, a Huawei account) and the other does not, mobile phone A and mobile phone B can perform the above - mentioned steps 901 - step 936. To verify during the FA migration between mobile phone A and mobile phone B (i.e., perform device - level authentication) to ensure the security of data between devices (such as FA1).

[0380] In some embodiments, if neither mobile phone A nor mobile phone B logs in to an account (for example, a Huawei account), mobile phone A and mobile phone B can perform the above - mentioned steps 901 - step 936. To verify during the FA migration between mobile phone A and mobile phone B to ensure the security of data between devices.

[0381] In some embodiments, if mobile phone A and mobile phone B log in to the same account (for example, a Huawei account), mobile phone A and mobile phone B can perform the above - mentioned steps 901 - step 936. To verify during the FA migration between mobile phone A and mobile phone B to further ensure the security of data between devices.

[0382] It should be noted that some of the steps in the above steps 901 - 936 can be optional, that is, they are not essential technical features of the application-level authentication solution. For example, steps 903 and 904 can be optional steps, that is, instead of querying the authenticated devices, the devices around can be directly viewed. For another example, steps 911 and 913 can be optional steps, that is, the creation success notification can be not sent. For another example, steps 916 and 917 can be optional steps, that is, the migration can be directly performed without the user's consent. For another example, steps 923b - 925 can be optional steps. At this time, mobile phone A can directly obtain the QR code picture generated by mobile phone B (for example, by scanning the QR code picture displayed on mobile phone B).

[0383] Next, in combination with a specific scenario, taking the camera application as an example, the UI interface of the application-level authentication provided by the embodiments of the present application will be introduced.

[0384] When traveling, a group of people need to take a group photo. Usually, they need to find a passerby or use a peripheral device such as a watch to control the camera button to take a photo. However, taking photos by finding a passerby or using a peripheral device such as a watch often makes it difficult to take a suitable photo because the situation during photo-taking is not clear. The present application provides a method. Based on the cross-device FA sharing technology, a connection is established between two devices. One device (for example, mobile phone A) is used as the camera phone, and the camera FA of the remote device is migrated to another device (for example, mobile phone B). In this way, the user can hold mobile phone B to observe the camera screen of mobile phone A and control the photo-taking, which helps the user take a more satisfactory photo and can improve the user experience.

[0385] As ​ shown, when the user uses mobile phone A to take a photo, mobile phone A displays the camera interface 1001. The camera interface includes a preview frame and a menu area. In response to the operation that user A clicks the migration button 1002 in the menu area, mobile phone A can send the camera interface of mobile phone A (the camera interface of mobile phone A can be regarded as an FA, for example, FA5) to mobile phone B. As ​ shown, mobile phone B can display the camera interface of mobile phone A, and mobile phone B can control the camera interface of mobile phone A.

[0386] Next, taking the camera application as an example, the specific implementation manner of the method provided by the embodiments of the present application will be described. The method provided by the embodiments of the present application can be applied to two near-field devices, such as mobile phone A and mobile phone B, and mobile phone A and mobile phone B are devices with different accounts. As ​ shown, it includes:

[0387] 1101. The user clicks the "Migrate" button in the camera application of mobile phone A.

[0388] Exemplarily, as ​As shown, user A can click the migration button 1002 in the photo taking interface 1001 .

[0389] 1102. The camera application of mobile phone A initiates a migration request to the DM of mobile phone A.

[0390] The information carried in the migration request includes the initiator package name (the local camera application package name), the connecting package name (the peer camera application package name), and the name of phone A.

[0391] Steps 1103 to 1132 may refer to the relevant description of steps 903 to 932 and will not be described in detail here. Part of steps 903 to 932 may be optional.

[0392] 1133. The camera application of mobile phone A requests the DEF of mobile phone A to migrate to FA5.

[0393] 1134. The DEF of mobile phone A sends the relevant information of FA5 to the DMS of mobile phone B.

[0394] FA5 related information may include shooting preview screen and menu bar information of the shooting interface.

[0395] 1135. The DMS of mobile phone B requests the DEF of mobile phone B to continue FA5.

[0396] Mobile phone B's DEF continues FA5 means that mobile phone B processes FA5 and displays it according to the received business information.

[0397] 1136. DEF on mobile phone B pulls up to display FA5.

[0398] like ​ As shown, mobile phone B can display and control the camera interface (FA5) of mobile phone A. This embodiment of the application uses cross-device FA sharing technology to establish a connection between the two devices, sharing FA5 of mobile phone A to mobile phone B. This allows mobile phone B to preview the camera interface and control the camera function of mobile phone A, helping users take more satisfactory photos and improving the user experience.

[0399] The following describes the UI interface for application-level authentication provided in the embodiment of this application, taking a karaoke application as an example, in combination with specific scenarios.

[0400] With the rapid development of the Internet, mobile KTV singing has become increasingly popular among users. For example, after a user opens a KTV singing application and authorizes the login, they can create a corresponding singing room and invite other users to enter the room by sharing the room link or invitation code. Other users can enter the same room by directly clicking the link or entering the invitation code to perform operations such as selecting songs and singing. However, there are many problems in the above sharing process: 1) When sharing the singing room created on the local end face-to-face with friends, it is necessary to forward the link through WeChat® or QQ®, and the sharing steps are relatively many; 2) When the peer user receives the singing room link and clicks to enter the room, if the KTV singing application is not installed on the peer device, it is necessary to jump to the application market to install the KTV singing application, and then click the link again to enter the room, resulting in a poor user experience; 3) The sharing and entry of the singing room strongly depend on applications such as WeChat®, QQ®, and KTV on the device, and it is impossible to immediately use a device with a better near-field experience (such as a TV).

[0401] In view of the KTV singing scenario, the present application provides a multi-device collaborative control solution based on FA sharing, which supports cross-device application-level mutual assistance sharing under the same network (for example, the same Wi-Fi network). For example, the KTV singing service of the local device (for example, mobile phone A) can be seamlessly transferred to other terminal devices (for example, a TV or a speaker); at the same time, there is no need for user account authorization and login, nor is it required that multiple terminal devices use the same system. In this way, the advantages of the audio-visual playback experience of devices such as TVs and speakers can be utilized, and the advantages of convenient interaction and easy sound pickup of devices such as mobile phones can be brought into play, with simple and fast operation steps, greatly improving the user experience.

[0402] As ​ shown in (a) of, after the user opens the KTV singing application on mobile phone A, mobile phone A can display the KTV singing interface 1201. In response to the user's operation of clicking the KTV button 1202 corresponding to the song "Red Beans", as ​ shown in (b) of, mobile phone A can display the KTV singing interface 1203 of Red Beans. In response to the user's operation of clicking the migration button 1204 (the migration button 1204 is used to migrate (send) the KTV singing interface of mobile phone A to other devices (for example, mobile phone B)), as ​ shown in (a) of, the mobile phone can pop up a pop-up window 1205, and the pop-up window 1205 may include nearby devices, and the nearby devices include authenticated devices (such as the bedroom TV, monica's Mate pad, etc.) and unauthenticated devices (such as the room TV, Brian's Mate pad, and Mate book X pro, etc.). In response to the user's operation of clicking the control 1206 corresponding to the room TV (an unauthenticated device), mobile phone A can send an authentication request message to mobile phone B. And, as ​ shown in (b) of, a prompt message 1207 "Waiting for confirmation from the peer" can be displayed below the room TV. As ​As shown, the TV may display a pop-up box 1210, which includes a prompt message "HUAWEI MATE30 (mobile phone A) requests to migrate the karaoke service to this machine, do you agree?" The pop-up box 1210 may also include a disagree button 1212 and an agree button 1213. In response to the user clicking the agree button 1213, as shown in FIG. ​ As shown, the TV may display a pop-up box 1214, which may include a QR code image generated by the TV and a prompt message 1215 "Scan for authentication, allow HUAWEI MATE30 to scan for authentication". At this time, the user of mobile phone A can scan the QR code image displayed on the TV, and then the TV can receive a karaoke interface from mobile phone A (the karaoke interface can be regarded as an FA, such as FA6). ​ As shown, the TV can display the karaoke interface 1217. Alternatively, in response to the user clicking the consent button 815, the TV can receive the karaoke interface (FA6) from the mobile phone A. ​ As shown, the TV can display the karaoke interface 1217. Further, as ​ As shown, mobile phone A can rearrange its UI to serve as a song-ordering console. When users order songs, switch songs, and perform other operations on mobile phone A, the song list information will be synchronously sent to the TV through the communication data channel, which can control the playback of music on the TV side.

[0403] The following uses a karaoke application as an example to illustrate the specific implementation of the method provided in the embodiment of the present application. The method provided in the embodiment of the present application can be applied to two near-field devices in the same network, such as mobile phone A and TV. Mobile phone A can be an Android system or a dual-frame system, and the TV can be a Hongmeng system. Mobile phone A and TV are different account devices. ​ Shown, including:

[0404] 1301. The user clicks the “Migrate” button in the Karaoke application of mobile phone A.

[0405] 1302. The karaoke application of mobile phone A initiates a migration request to the DM of mobile phone A.

[0406] The information carried in the migration request includes the initiating end package name (the local end's karaoke application package name), the connecting end package name (the peer end's karaoke application package name), and the name of mobile phone A.

[0407] Steps 1303 to 1332 may refer to the relevant description of steps 903 to 932, which will not be repeated here. Part of steps 903 to 932 may be optional.

[0408] 1333. The karaoke application of mobile phone A requests the DEF of mobile phone A to migrate to FA6.

[0409] 1334. The DEF of mobile phone A sends relevant information of FA6 to the DMS of the TV.

[0410] The relevant information of FA6 may include song information for karaoke singing. The song information includes at least one of the song name (e.g., Red Bean), lyrics, audio information, and video information.

[0411] 1335. The DMS of the TV requests the DEF of the TV to continue FA6.

[0412] 1336. The DEF of the TV pulls up and displays FA6.

[0413] If the TV installs a karaoke application, the DEF of the TV can detect whether the karaoke application and account of the TV are logged in, and prompt the user to log in to the karaoke application so that the karaoke application can display FA6 sent by mobile phone A.

[0414] If the TV does not install a karaoke application, the DEF of the TV can pull up FA6, that is, provide the ability to display FA6, without pre-installing a karaoke application, and can achieve the effect of instant use of the karaoke service.

[0415] The embodiment of this application provides a near-field application layer data sharing service for the karaoke entertainment scenario, which can realize the one-key migration of FAs across devices and operating systems, does not need to rely on any third-party platform, does not require pre-installation of a karaoke application, can instantaneously use the karaoke service, quickly create a mobile karaoke room, can improve the user experience, has simple operations, and enhances the entertainment experience.

[0416] Next, in combination with a specific scenario, taking a shopping application as an example, the UI interface of the application-level authentication provided by the embodiment of this application will be introduced.

[0417] With the rapid development of the Internet, especially the popularization of mobile Internet, online shopping has become an essential element in the daily life of most people. Mobile phones and tablets, as the most commonly used terminal devices in online shopping, will undoubtedly greatly enhance the market competitiveness of terminal devices if they can provide a better improvement in the shopping experience of users. Taking mobile phone shopping as an example, during various shopping festivals, merchants will launch many discount activities such as full reduction. In order to pursue more affordable prices, users often find friends and family around them to split the bill for certain items to reach the full reduction amount set by the merchant. In this process, there are the following pain points: 1) When sharing a certain item with friends face to face, it is also necessary to forward it through WeChat®, and the sharing steps are relatively many; 2) In order to participate in the discount, users will frequently switch between the product selection interface and the shopping cart, and the operations are trivial and complex; 3) When multiple people split the bill to buy products from a certain merchant, operations such as sharing products, adding to the shopping cart, and switching interfaces will be more frequent. After completing the payment, an additional transfer operation is required, which is extremely inconvenient. In response to such problems, some manufacturers have proposed a solution for face-to-face splitting of the bill, which can share the products to be split the bill with other users around through WeChat® scanning code to achieve fast face-to-face splitting of the bill operation. However, this solution has some drawbacks: on the one hand, there are relatively large restrictions on the merchant platform and usage scenarios, and on the other hand, from the payment by user A to sharing the QR code with user B, and then user B opening WeChat to scan the code, browse, and purchase the product, the sharing process still relies on the WeChat platform and the steps are relatively many.

[0418] This application provides an application layer data sharing service based on near-field FA sharing for the online shopping scenario, which supports one-click synchronization of shopping cart information between multiple terminal devices under the same network (for example, the same Wi-Fi network). It can migrate the shopping cart of one terminal device (the shopping cart can be regarded as an FA, for example, FA7) to another terminal device. The products in the shopping carts of the two devices can be settled together to enjoy the full reduction discount, and then pay separately to save the trouble of mutual transfer. The operation steps are simple and fast, which can greatly improve the user experience of split-bill shopping. At the same time, because the near-field FA sharing ability is a basic ability provided by the system service, it does not require the same operating system, nor does it require logging in to the same device account (for example, Huawei account), and even does not require a shopping application to be installed on the device. It has high versatility, can be used by various e-commerce platforms, and has a small adaptation cost, enabling more users to enjoy a more convenient online shopping experience.

[0419] Exemplarily, as ​ shown, after the user opens the shopping application on mobile phone A, they can enter the shopping cart interface 1401. In response to the user's operation of clicking the migration button 1402 (the migration button 1402 is used to migrate (send) the shopping cart of mobile phone A to other devices (for example, mobile phone B)) on the shopping cart interface 1401, as ​As shown in (a) of [description], the mobile phone can pop up a pop-up window 1403, and the pop-up window 1403 can include nearby devices. The nearby devices include authenticated devices (such as bedroom TV, monica's Mate pad, etc.) and unauthenticated devices (such as room TV, HUAWEI P20, and Mate book X pro, etc.). In response to the user's operation of clicking on the control 1404 corresponding to HUAWEI P20 (an unauthenticated device), mobile phone A can send an authentication request message to mobile phone B. And, as ​ shown in (b) of [description], a prompt message 1405 "Waiting for confirmation from the other end" can be displayed below HUAWEI P20. As ​ shown, if mobile phone B (HUAWEI P20) receives the authentication request message sent by mobile phone A when displaying the desktop, mobile phone B can display a pop-up window 1410. The pop-up window 1410 includes a prompt message "HUAWEI MATE30 (mobile phone A) requests to migrate the shopping cart to this device. Do you agree?", and the pop-up window 1410 can include a disagree button 1412 and an agree button 1413. In response to the user's operation of clicking on the agree button 1413, as ​ shown, mobile phone B can display a pop-up window 1415. The pop-up window 1415 can include a QR code picture generated by mobile phone B, and can also include a prompt message 1416 "Scan to bind. Allow HUAWEI MATE30 to scan for authentication". At this time, the user of mobile phone A can scan the QR code picture displayed by mobile phone B. Then, mobile phone B can receive the shopping cart (FA6) from mobile phone A, or, in response to the user's operation of clicking on the agree button 1413, mobile phone B can receive the shopping cart (FA6) from mobile phone A. As ​ shown, mobile phone B can display the shared shopping cart in the shopping cart interface 1417. The shared shopping cart includes both the items added by "me" and the items added by user A (the user of mobile phone A). In addition, mobile phone B can also migrate its own shopping cart (for example, FA7) to mobile phone A. In this way, as ​ shown, mobile phone A can display the shared shopping cart in the shopping cart interface 1407. The shared shopping cart includes both the items added by "me" and the items added by user B (the user of mobile phone B). In this way, users can achieve joint shopping with one key, without relying on any third-party platforms for sharing, saving the cumbersome steps of sharing items with each other and transferring money to each other, and greatly improving the shopping experience.

[0420] Next, taking a shopping application as an example, the specific implementation manner of the method provided in the embodiments of the present application will be described. The method provided in the embodiments of the present application can be applied to two near-field devices, such as mobile phone A and mobile phone B, and mobile phone A and mobile phone B are devices with different accounts. As ​ shown, it includes:

[0421] 1501. The user clicks the "Migrate" button in the shopping app on mobile phone A.

[0422] As ​ shown, after the user opens the shopping app on mobile phone A, selects products and adds them to the shopping cart, and then enters the shopping cart interface 1401. The user can click the migrate button 1402 in the shopping cart interface 1401. The migrate button 1402 is used to migrate (send) the shopping cart on mobile phone A to other devices (for example, mobile phone B).

[0423] 1502. The shopping app sends a migration request (sharing request) to the DM on mobile phone A.

[0424] The information carried in the migration request includes the originating package name (the package name of the local shopping app), the receiving package name (the package name of the remote shopping app), and the name of mobile phone A. The originating package name is, for example, com.huawei.vmall, and the receiving package name is, for example, com.huawei.vmall.

[0425] Steps 1503 - 1532 can refer to the relevant descriptions of steps 903 - 932 and will not be elaborated here. Some of the steps in steps 903 - 932 can be optional.

[0426] 1533. The shopping app on mobile phone A requests the DEF on mobile phone A to migrate FA7.

[0427] 1534. The DEF on mobile phone A sends the relevant information of FA7 to the DMS on mobile phone B.

[0428] The relevant information of FA7 includes the product information in the shopping cart. The product information includes at least one of the product name, product link, product price, and other information.

[0429] 1535. The DMS on mobile phone B requests the DEF on mobile phone B to continue FA7.

[0430] 1536. The DEF on mobile phone B pulls up and displays FA7.

[0431] The DEF on mobile phone B pulls up FA7. As ​ shown, mobile phone B can display the shared shopping cart in the shopping cart interface 1417, which contains both one product in its own shopping cart and three products selected by user A. At this time, user B can intuitively see all the products for joint purchase. After selecting some or all of the products in the shopping cart, the user can check whether the amount meets the full reduction activity, realizing a fast joint purchase function.

[0432] In addition, the product information in the shared shopping cart can be updated in real time. For example, if there are new products in the shopping cart of the device initiating the migration (e.g., mobile phone A), the shared shopping cart of the destination device (e.g., mobile phone B) can also be refreshed immediately.

[0433] Furthermore, when user B clicks the "Settle" button, mobile phone B can initiate a payment request to user A and carry payment-related information, which can include the receiving platform and the payment amount, etc. Among them, the payment amount can be: the total amount of the products purchased by each person - (the total amount of each person / the total amount of the shared shopping cart) * the discount value. After the payment is completed, the shared shopping cart is emptied, and a group-buying shopping process ends.

[0434] Based on the method provided in the embodiments of the present application, the shopping cart of one terminal device (the shopping cart can be regarded as a FA, e.g., FA7) can be migrated to another terminal device. The products in the shopping carts of the two devices can be settled together to enjoy the full reduction discount, and then pay separately to save the trouble of mutual transfer. The operation steps are simple and fast, which can greatly improve the user experience of group-buying shopping.

[0435] In some other embodiments, in a home environment, a user holds a mobile phone and a TV and is participating in an event where a purchase of 400 yuan can get a 100 yuan discount during a shopping festival. In the traditional shopping scenario, the user will frequently switch between the product details page and the shopping cart page to view or modify the content of the shopping cart when selecting products with the mobile phone. Based on the method provided in the embodiments of the present application, the user can migrate the shopping cart to the TV, browse and select products on the mobile phone, and can view the content of the shopping cart on the TV at any time, saving the cumbersome operation of repeatedly switching pages on the mobile phone and improving the user experience.

[0436] In some other embodiments, the user has selected some products and added them to the shopping carts on two mobile phones (mobile phone A and mobile phone C) respectively. The user can migrate the shopping carts of both mobile phone A and mobile phone C to TV B at the same time. After mobile phone A and mobile phone C are respectively authenticated with TV B, the group members on mobile phone A can include (the shopping application of A, the shopping application of B); the group members on mobile phone C can include (the shopping application of C, the shopping application of B); the group members on TV B include (the shopping application of A, the shopping application of B, and the shopping application of C), and the group on the TV includes three members. That is, the shopping application on the TV has performed application-level authentication with the shopping applications on mobile phone A and mobile phone C respectively, and can communicate with the shopping applications on mobile phone A and mobile phone C respectively in the future.

[0437] It should be understood that the shopping cart FA migration scenario implemented based on the near-field FA sharing ability is mainly applicable to networking environments such as home environments and work environments. For scenarios where near-field networking (short-distance networking) is not possible, this solution also has reference value. For example, the content of the shopping cart can be shared and synchronized in real time using the Internet. Or, an e-commerce platform can integrate the shopping cart in the Internet environment into its own shopping application and achieve sharing through its own cloud service and account.

[0438] Next, in combination with a specific scenario, taking a mail application as an example, the UI interface of the application-level authentication provided by the embodiments of the present application will be introduced.

[0439] Currently, the usage scenarios of office software such as email are undergoing some changes. In addition to the traditional office and home scenarios, business trips / transportation / waiting / walking outdoors have all become usage scenarios for office workers. Existing manufacturers provide email clients on various mobile platforms, enabling users to access their emails on multiple devices. However, when users switch between mobile and non-mobile working states, they cannot switch seamlessly, and the operations cannot be continuous, resulting in a poor user experience. For example, when receiving an email notification on a smartwatch and wanting to reply on a mobile phone or tablet, the user still needs to turn on the mobile phone / tablet, log in to the email, find the email, and then reply, which is a cumbersome operation and a poor user experience. Currently, the Handoff technology proposed by Apple allows users to switch from one Apple device (e.g., Mac, iPhone, iPad, or Apple Watch, etc.) to another nearby Apple device to continue working without losing the task progress. However, this requires that the devices for email handoff must be logged in with the same Apple ID, have the same email client installed in advance, and log in to the email account; and this technology cannot select the push device. For example, when it is necessary to push a certain email to a TV for display in a meeting room, since the two devices are not logged in with the same Apple ID, the handoff cannot be achieved.

[0440] The present application provides an application continuation service based on near-field cross-device FA migration for the scenario of business people switching between mobile and non-mobile working, supporting one-key migration of emails between multiple terminal devices. For example, the watch can one-key pull up the email viewing interface on the mobile phone side and directly reach the email body in one step on the mobile phone side. Another example is that for the email draft being edited on the mobile phone side, the present application also supports seamlessly transferring it to other devices (e.g., other mobile phones, tablets, or TVs) with one key to continue, providing an excellent multi-device email collaboration experience. The present application does not require the same system, does not require devices to be logged in with the same account, and does not even require both end devices to install an email application, with a wide range of applications.

[0441] Exemplarily, after a user receives and opens an email on mobile phone A, as ​As shown in the figure, mobile phone A can display the email interface 1601 (the email interface 1601 can be regarded as a FA, for example, FA8). In response to the user's operation of clicking the migration button 1602 on the email interface 1601 (the migration button is used to migrate (send) the email interface of mobile phone A to other devices (such as a TV)), as ​ shown in (a) of, mobile phone A can pop up a dialog box 1603. The dialog box 1603 can include nearby devices, and the nearby devices include authenticated devices (such as monica’s Mate pad) and unauthenticated devices (such as a TV, HUAWEI P20, and Mate book X pro). In response to the user's operation of clicking the control 1604 corresponding to the TV (an unauthenticated device), mobile phone A can send an authentication request message to the TV. And, as ​ shown in (b) of, a prompt message 1605 "Waiting for confirmation from the other end" can be displayed below the TV. As ​ shown in the figure, the TV can display a dialog box 1610. The dialog box 1610 includes a prompt message "HUAWEI MATE30 (mobile phone A) requests to migrate the email to this device. Do you agree?" The dialog box 1610 can also include a disagree button 1612 and an agree button 1613. In response to the user's operation of clicking the agree button 1613, as ​ shown in the figure, the TV can display a dialog box 1614. The dialog box 1614 can include a QR code picture generated by the TV, and can also include a prompt message 1615 "Scan the code for authentication. Allow HUAWEI MATE30 to scan the code for authentication". At this time, the user of mobile phone A can scan the QR code picture displayed on the TV. Then, the TV can receive the email interface (FA8) from mobile phone A. As ​ shown in the figure, the TV can display the email interface 1616. Or, in response to the user's operation of clicking the agree button 1613, the TV can receive the email interface (FA8) from mobile phone A. As ​ shown in the figure, the TV can display the email interface 1616.

[0442] Taking the email application as an example below, the specific implementation of the method provided by the embodiments of the present application will be described. The method provided by the embodiments of the present application can be applied to two near-field devices, such as mobile phone A and a PC. Mobile phone A can be an Android system, and the PC can be a HarmonyOS system. Mobile phone A and the PC are devices with different accounts. As ​ shown in the figure, it includes:

[0443] 1701. The user clicks the "Migrate" button in the email application of mobile phone A.

[0444] The user opens an email for editing on the mobile phone and clicks the "Migrate" button on the editing interface.

[0445] 1702. The email application of mobile phone A initiates a migration request to the DM of mobile phone A.

[0446] The information carried in the migration request includes the initiating end package name (the local end's email application package name), the connecting end package name (the peer end's email application package name), and the name of mobile phone A.

[0447] Steps 1703 to 1732 may refer to the relevant description of steps 903 to 932 and will not be described in detail here. Part of steps 903 to 932 may be optional.

[0448] 1733. The email application of mobile phone A requests the DEF of mobile phone A to migrate to FA8.

[0449] The email application may carry parameters of the current device and the target device (eg, identifiers of the current device and the target device) to request the DEF of mobile phone A to proceed to FA8.

[0450] 1734. The DEF of mobile phone A sends the relevant information of FA8 to the DMS of the TV.

[0451] The relevant information of FA8 may include email content information, which may include subject, body, attachments and other information.

[0452] 1735. The TV's DMS requests the TV's DEF to continue the service.

[0453] 1736. The DEF on the TV pulls up to display FA8.

[0454] If the TV has an email client installed, the TV's DEF can detect whether the email client and account are logged in, and prompt the user to log in to the email account, so that the email application can pull up and display FA8, that is, display the email interface migrated from mobile phone A.

[0455] If the TV doesn't have an email client installed, the TV's DEF can pull up and display FA8, encoding and rearranging FA8 for display. This allows devices that aren't logged in or don't have an email client installed to display email content, preventing the leakage of private information such as email accounts. Additionally, if the TV's DEF doesn't support displaying FA8, you can download and install a FA that can display FA8 from the app store (this FA can be developed by a third-party app manufacturer).

[0456] Further, the user can edit, reply to, etc. emails on the TV, and the content of the edited or replied emails can be transmitted back to mobile phone A through the data communication channel and sent out based on the account information of mobile phone A. In this way, even if the TV does not have a mailbox client installed or the mailbox account is not logged in, one-key migration can be achieved, improving the user experience and office efficiency. The migration device can only be used for display and editing, and the final email sending and receiving are all executed by the migration initiating end. The migrated device can only view the emails actively pushed by the initiating end, and the content is actively destroyed after the process ends, achieving true email following the person and seamless switching.

[0457] This application enables emails to be transferred between multiple devices, without requiring the same device account to be logged in, nor requiring all devices to have a mailbox client installed and the mailbox account to be logged in, greatly expanding the scope of available devices.

[0458] In addition, if networking and authentication have been completed between two devices, directly clicking the migration button can complete the migration, which is more convenient and fast. For example, assume that networking and authentication have been completed among a watch, a mobile phone, and a PC, as ​ shown. After the user's watch receives an email notification, it can display the email notification interface 1701, prompting the user that there is an email. In response to the user's operation of clicking the view button 1702, as ​ shown, the watch can directly pull up the email view interface 1704 on the mobile phone side (the watch can send an email view request to the mobile phone, and the mobile phone can directly display the email view interface 1704), directly reaching the email body in one step. During the process of the user editing and replying to an email on the mobile phone, if a document needs to be inserted but the document is saved on the PC, the user can click the migration button 1705 on the mobile phone to migrate the email to the PC, as ​ shown. The PC can display the email editing interface 1706. After the user inserts an attachment in the email editing interface 1706, they can click the migration button 1707 to migrate the email with the attachment back to the mobile phone. In this way, the watch, mobile phone, and PC can work together conveniently and quickly, providing a high user experience.

[0459] This application is based on the near-field cross-device FA migration technology to achieve one-key migration and seamless transfer of emails between mobile and non-mobile offices, greatly enhancing the multi-device collaborative office experience. The migration of emails among multiple devices is not restricted by the user account / mailbox client / mailbox account, and can cover various devices under the same network, greatly expanding the usage scenarios of email migration.

[0460] In the above embodiment, the receiving party (passive migration device, such as mobile phone B, TV, etc.) generates the QR code information, and the initiating party (active migration device, such as mobile phone A) parses the QR code information of mobile phone B and joins the group created by mobile phone B for authentication.

[0461] In some other embodiments, the initiator (active migration device, such as mobile phone A) can also generate the QR code information, and the receiver (passive migration device, such as mobile phone B, TV, etc.) authenticates according to the QR code information of mobile phone A.

[0462] Exemplarily, as ​ shown, user A can select the migration option 1801 (the migration option 1801 is used to migrate (send) the KTV interface of the TV to other devices (such as mobile phone B)) on the KTV interface 1800 of the TV. Optionally, user A can use a control device (such as a remote control, mobile phone, etc.) to select the "Migration" option. Or, if the TV is a touch device, user A can directly click the "Migration" option to select the "Migration" option. As ​ shown, the TV can pop up a dialog box 1802, and the dialog box 1802 can include a QR code picture generated by the TV, and can also include a prompt message 1803 "Scan the code for authentication, allow other devices to scan and join my karaoke room". User B can use mobile phone B to scan the QR code picture displayed on the TV (mobile phone B can use the scan entry provided by a third-party application (such as a KTV application, etc.), or can use the scan entry provided by the system itself). After that, as ​ shown in (a) of ​ mobile phone B can display the KTV interface 1804, and the avatar 1805 of user A (the avatar of the account of the KTV application logged in on the TV, or the avatar of the device account (such as a Huawei account) logged in on the TV) can be displayed at the bottom layer of the lyrics, indicating that the current user A is singing a song. In response to the user's operation of clicking the song selection button 1806, as ​ shown in (b) of ​ mobile phone B can display a dialog box 1807. In response to the user's operation of clicking the duet button 1808, as ​ shown, the avatar 1811 of user A (the avatar of the account of the KTV application logged in on the TV, or the avatar of the device account (such as a Huawei account) logged in on the TV) and the avatar 1810 of user B (the avatar of the account of the KTV application logged in on mobile phone B, or the avatar of the device account (such as a Huawei account) logged in on mobile phone B) indicate that user B and user A are singing the same song in duet.

[0463] Next, taking the KTV application as an example, the specific implementation manner of the application-level authentication method provided in the embodiments of the present application will be described. The method provided in the embodiments of the present application can be applied to two near-field devices, such as a TV and mobile phone B. The TV and mobile phone B are devices with different accounts (such as not the same Huawei account), and both the TV and mobile phone B have the KTV application opened. As ​ shown, it includes:

[0464] 1901. The user selects the "Migration" option on the KTV interface of the TV.

[0465] For example, as​ As shown, the user can select migration option 1801 in the karaoke interface of the TV. (Migration option 1801 is used to migrate (send) a series of karaoke interfaces (for example, this series of karaoke interfaces can be regarded as FA9) on mobile phone A to another device (for example, mobile phone B). The migration option may also be referred to as a sharing option, a sending option, etc., which is not limited in this application.

[0466] Optionally, the user may select the "Migrate" option using a control device (eg, a remote control, a mobile phone, etc.). Alternatively, if the TV is a touch-sensitive device, the user may directly click the "Migrate" option to select the "Migrate" option.

[0467] Optionally, after selecting the migration option 1801 , the user may further select a device to be migrated, for example, mobile phone B.

[0468] 1902. The TV's QR code recognition module initiates a QR code generation request to the TV's HarmonyOS tag management module.

[0469] For example, the input parameters for a QR code generation request include a Bundle object and an asynchronous callback. The Bundle object contains the source package name (the local karaoke application package name) and the destination package name (the peer karaoke application package name or the package name of the FA to be migrated) required for the karaoke service. The asynchronous callback contains the QR code creation result. If the creation is successful, the QR code fields are obtained; if the creation fails, an error code is obtained.

[0470] 1903. The TV's Harmony tag management module requests the TV's DM for the TV's device information.

[0471] The device information of the TV may include the name of the TV, network ID (netId), and device IP (deviceIP), etc.

[0472] The Bundle object saves the device information obtained by the HarmonyOS tag management module to the device management, which is used to create a group and subsequently transmit information such as the client application package name to the peer device through the channel.

[0473] 1904. The TV's DM generates a PIN.

[0474] The TV's DM can generate a random PIN. The PIN can be a random number of digits. Optionally, the TV's DM can also generate a token. The token can be a random string of digits.

[0475] 1905. Optionally, the TV DM calls the security management module to obtain local device connection parameters.

[0476] Among them, the local device connection parameters may include the local network ID (netId), device IP (deviceIP), Bluetooth address (BtMac), and Wi-Fi address (Wi-FiPort). Among them, the netId is saved locally.

[0477] 1906a. The DM of the TV calls the security management module to create a group.

[0478] Among them, the created group may be (local device name (i.e., TV, such as HUAWEI TV), package name of the local KTV application of the device, (the peer device name may be blank), package name of the peer KTV application / package name of the FA to be migrated). Currently, this group lacks at least one member and allows other devices to join as members.

[0479] 1906b. Optionally, after the security management module successfully creates a group, it sends a callback notification to the DM of the TV.

[0480] 1907. After the DM of the TV receives the callback notification, it sends the PIN, token, and device information of the TV to the HarmonyOS label management module.

[0481] The DM of the TV saves the group name (groupName) locally, packs the PIN, token, and device information of the TV into a Bundle type, and passes it to the HarmonyOS label management module through the device management callback.

[0482] 1908a. The HarmonyOS label management module generates a QR code picture based on the PIN, token, and device information of the TV.

[0483] 1908b. The HarmonyOS label management module sends the QR code information to the QR code recognition module.

[0484] 1908c. The QR code recognition module generates a QR code picture according to the QR code information and displays the QR code picture.

[0485] Among them, the QR code recognition module can call the display function of the TV to display the QR code picture on the TV screen.

[0486] 1909a. Mobile phone B opens the QR code recognition module to scan the QR code picture displayed on the TV.

[0487] 1909b. The QR code recognition module of mobile phone B recognizes the QR code information (which can also be called the QR code label) in the QR code picture, launches the HarmonyOS label management module, and passes the QR code information to it.

[0488] 1909c. The HarmonyOS label management module parses the QR code information and extracts the fields (strings) stored in the QR code information.

[0489] In 1910, the HarmonyOS label management module of mobile phone B sends an authentication request message to the DM of mobile phone B and registers a callback.

[0490] The authentication request message includes fields parsed from the QR code information.

[0491] In 1911a, the DM of mobile phone B processes the authentication request message.

[0492] The DM of mobile phone B can split the fields included in the authentication request message to obtain the deviceIp and Wi-FiPort fields, and call the communication module interface according to deviceIp and Wi-FiPort to create a communication channel between mobile phone B and the TV.

[0493] In 1911b, optionally, the DM of mobile phone B sends an authentication request message to the DM of the TV through the communication module.

[0494] The DM of mobile phone B can set the token as the parameter requestId. It can be understood that the DM of mobile phone B can also send information such as the device ID of mobile phone B to the DM of the TV through the communication module.

[0495] In 1912, optionally, the DM of the TV verifies the token.

[0496] The DM of the TV extracts the token based on the parameter requestId, compares the extracted token with the token saved locally. If they are the same, it agrees to create a secure communication channel (the secure communication channel can be an encrypted protected communication channel for example) between the two devices (i.e., the TV and mobile phone B), and sends group information to mobile phone B through this secure communication channel. The group information includes the network ID of the TV, the group ID (groupId), group type (groupType) and group name (groupName) of the group created by the TV, etc.

[0497] In 1913, the DM of mobile phone B receives and saves the group information sent by the TV.

[0498] In 1914, the DM of mobile phone B calls the security management module to obtain all group information with a trusted relationship with the peer device, and then traverses and queries through the security management module whether the KTV application of the TV has access rights to the group.

[0499] If there is no permission, the device management joins the specified group through HiChain. The successful group join will trigger the onFinish callback of both devices. In this method, the HiChain is called to write the package name information of the peer device for subsequent query of the application-level trusted relationship. If there is already permission, step 1915 is executed.

[0500] In 1915, the DMS of mobile phone B receives relevant information of FA9 of DEF from the TV.

[0501] The relevant information of FA9 may include song information for karaoke, and the song information includes at least one of the song name (e.g., Red Bean), lyrics, audio information, and video information.

[0502] Optionally, operations such as song selection and song switching on mobile phone B, as well as playlist information, will be synchronously sent to the TV through a secure communication channel, and the music playback on the TV side can be controlled.

[0503] In some embodiments, if one of the TV and mobile phone B logs in to an account (e.g., a Huawei account) and the other does not, the TV and mobile phone B can perform the above steps 1901 - step 1915. For verification during the FA migration between the TV and mobile phone B (i.e., device-level authentication) to ensure the security of data between devices.

[0504] In some embodiments, if neither the TV nor mobile phone B logs in to an account (e.g., a Huawei account), the TV and mobile phone B can perform the above steps 1901 - step 1915. For verification during the FA migration between the TV and mobile phone B to ensure the security of data between devices.

[0505] In some embodiments, if the TV and mobile phone B log in to the same account (e.g., a Huawei account), the TV and mobile phone B can perform the above steps 1901 - step 1915. For verification during the FA migration between the TV and mobile phone B to further ensure the security of data between devices (e.g., the relevant information of FA9).

[0506] It should be noted that some of the above steps 1901 - step 1915 may be optional, that is, they are not essential technical features of the device-level authentication solution. For example, step 1905 may be an optional step. For example, the DM of the TV can obtain the local device connection parameters from other modules. Another example is that step 1906b may be an optional step, that is, after the security management module successfully creates a group, it may not send a callback notification to the DM of the TV. Another example is that steps 1911b and 1912 may be optional steps, that is, the DM of mobile phone B may not send a token to the DM of the TV, and the DM of the TV does not need to verify the token either.

[0507] Of course, mobile phone C (the device accounts of mobile phone C and mobile phone B are different, for example, they are not logged in to the same Huawei account) can also join the group created by the TV by scanning the QR code (the specific process can refer to steps 1809 - 1818). In this way, multiple devices can quickly launch FA9 based on QR code scanning without pre-installation and can immediately use the service; and after multiple devices scan the code, a trust circle can be established for information interaction. For example, information such as playlists among multiple devices can be refreshed and synchronized in real time, and multiple devices (such as mobile phone B or mobile phone C) can cooperate to control another device (such as the TV), realizing multi-device cooperative control and achieving a truly mobile KTV experience.

[0508] In some other embodiments, the initiator (the device for active migration, such as the TV) can generate a QR code picture (for example, execute steps 1901 - 1908c), and one or more receivers (the devices for passive migration, such as mobile phone B and mobile phone C) can authenticate according to the QR code picture of the TV (for example, execute steps 1909a - 1914). After passing the authentication, the receivers can migrate the shopping cart, live broadcast room, emails, etc. to the TV, so as to achieve the effect of sharing information such as shopping carts, live broadcast rooms, and emails among multiple devices (such as the TV, mobile phone B, and mobile phone C). Information such as shopping cart product information, live video stream, and email content among multiple devices can be refreshed and synchronized in real time, and multiple devices (such as the TV, mobile phone B, and mobile phone C) can cooperate to control another device (such as the TV), realizing multi-device cooperative control and achieving a truly cooperative shopping, live broadcast, or email editing experience.

[0509] It should be noted that for each UI interface provided in the embodiments of the present application, such as those in the above text ​ , ​ , ​ , ​ , ​ , ​ , ​ , ​ etc., the interface design of each UI interface is only a schematic, and does not limit the positions, names, shapes, etc. of various elements (such as buttons, icons, text, etc.) in the UI interface. For example, ​ The button 802 (originally located in the upper left corner of interface 801) in ​ can also be located in the lower right corner of interface 801, and the text displayed on button 802 can also be "Share", "Transfer", etc. In some embodiments, the elements of different UI interfaces can be rearranged and combined into the same UI interface. For example, ​The buttons 503 and 504 in (b) thereof. The embodiments of the present application do not limit the jump relationship between UI interfaces. For example, if the embodiments of the present application describe a jump from the first UI interface to the second UI interface, it is only a schematic illustration of a jump relationship between the first interface and the second interface, and other jump relationships are not limited. For example, as ​ shown in (b) thereof, in response to the user's operation of clicking the binding button 509, as ​ shown in (b) thereof, the mobile phone can directly display the scanning interface 512. The embodiments of the present application also do not limit the jump method between UI interfaces (for example, if the embodiments of the present application describe jumping to the second UI by clicking the first button on the first UI interface, it is only a schematic illustration of a jump method between the first interface and the second interface, and other jump methods are not limited). For example, as ​ shown, in response to the user's operation of a specific gesture (such as three-finger swipe down, knuckle tap, etc.), as ​ shown in (a) thereof, the mobile phone can display a pop-up window 803.

[0510] The embodiments of the present application provide a function migration method, as ​ shown, including:

[0511] 2001. The first device sends a first request to the second device.

[0512] Wherein, the first request carries the identifier of the first device, the identifier of the first application, and the identifier of the second application. The first request may be the authentication request message in the above embodiments, and related descriptions will not be elaborated here.

[0513] In a possible implementation manner, in response to the user's first operation on the first application of the first device, a first pop-up window is displayed. The first pop-up window includes the identifiers of the devices in the same network as the first device; in response to the user's second operation of selecting the second device in the first pop-up window, a first request is sent to the second device. Exemplarily, the first pop-up window here may be the pop-up window 508 shown in (b) of ​ or the pop-up window 803 shown in (a) of ​ etc.

[0514] Wherein, the devices in the same network as the first device include trusted devices and untrusted devices; wherein, the trusted devices include the devices logged in with the same account as the first device, the devices that have undergone device-level authentication with the first device, or the devices that have undergone application-level authentication with the first application of the first device; the untrusted devices include the devices not logged in with the same account as the first device, the devices that have not undergone device-level authentication with the first device, or the devices that have not undergone application-level authentication with the first application of the first device. Wherein, the first device may be the mobile phone A in the above embodiments.

[0515] In 2002, the second device receives a first request from the first device.

[0516] After the first device receives the first request, it may display a first pop-up window for prompting the user whether to agree to add the first application of the first device to the first group, and receive an approval instruction from the user. Exemplarily, the first pop-up window here may be the pop-up window 531 shown in (a) of ​ , or may be the pop-up window 812 shown in (a) of ​ .

[0517] Among them, the second device may be the mobile phone B in the above embodiments.

[0518] In 2003, the second device creates a first group, and the members of the first group include the second application of the second device.

[0519] Before the second device creates the first group, it may determine that the second device currently has no second group according to the identifier of the first device, where the members of the second group include the first device and the second device.

[0520] Before the second device creates the first group, it may determine that the second device currently has no third group according to the identifier of the first device, the identifier of the first application, and the identifier of the second application, where the members of the third group include the first application of the first device and the second application of the second device.

[0521] In 2004, the second device sends a first response to the first device.

[0522] The first response may include a personal identification number PIN corresponding to the first group and / or the communication connection information of the second device.

[0523] In 2005, the first device receives the first response from the second device.

[0524] The first response is used to indicate the first group created by the second device, and the members of the first group include the second application of the second device.

[0525] In 2006, the first device sends a second request to the second device.

[0526] The second request is used to apply to add the first application of the first device to the first group.

[0527] In a possible implementation manner, the second device may display a QR code picture, which includes a personal identification number PIN corresponding to the first group and / or the communication connection information of the second device. The first device may scan the QR code picture displayed by the second device to obtain the personal identification number PIN corresponding to the first group and / or the communication connection information of the second device, and the first device may send the second request to the second device according to the PIN and / or the communication connection information of the second device.

[0528] Optionally, the first device sends a second request to the second device according to the PIN and / or the communication connection information of the second device.

[0529] 2007. The second device receives the second request from the first device.

[0530] The second device may add the first application of the first device to the first group according to the second request.

[0531] Optionally, the second device may send a second response to the first device, and the first device may receive the second response, where the second response is used to indicate that the first application of the first device has joined the first group.

[0532] 2008. The first device migrates the first function in the first application to the second application of the second device, and the first function includes one or more UIs.

[0533] In a possible implementation manner, migrating the first function in the first application to the second application of the second device includes: sending the service information of the first function to the second device; when the first application is a live broadcast application, the service information of the first function includes at least one of the video stream, audio stream, and barrage information of the live broadcast room of the first device; or when the first application is a camera application, the service information of the first function includes the shooting preview screen or the menu bar information of the shooting interface; or when the first application is a KTV application, the service information of the first function includes at least one of the song name, lyrics, audio information of the song, video information of the song, and control interface of the song; or when the first application is a shopping application, the service information of the first function includes the commodity information in the shopping cart; or when the first application is an email application, the service information of the first function includes at least one of the subject, body, and attachment of the email.

[0534] Optionally, the first device may create a second group, where the members of the second group include the first application of the first device and the second application of the second device.

[0535] 2009. The second device receives the first function in the first application migrated by the first device, where the first function includes one or more UIs.

[0536] ​ The first device or the second device in the embodiments of may be the mobile phone A and mobile phone B in the foregoing embodiments respectively, ​ For the parts not detailed in the embodiments of, reference may be made to the foregoing embodiments, and details are not described herein again.

[0537] The embodiments of the present application provide a function migration method, as ​ shown, including:

[0538] 2101. The first device sends a first request to the second device.

[0539] The first request carries the identifier of the first device.

[0540] 2102. The second device receives the first request from the first device.

[0541] 2103. The second device sends a first response to the first device.

[0542] The first response is used to indicate the first group created by the second device, and the members of the first group include the second device.

[0543] 2104. The first device receives the first response from the second device.

[0544] 2105. The first device sends a second request to the second device, and the second request is used to apply to join the first device into the first group.

[0545] 2106. The first device migrates the first function in the first application to the second device. The first application is any application in the first device, and the first function includes one or more graphical user interfaces (UIs).

[0546] ​ In the embodiments, the first device or the second device can be the mobile phone A and the mobile phone B in the foregoing embodiments respectively, and the first request can be the authentication request message in the foregoing embodiments, etc. ​ For the parts not detailed in the embodiments, reference can be made to the foregoing embodiments and will not be elaborated herein.

[0547] An embodiment of the present application provides a function migration method, as ​ shown, including:

[0548] 2201. The first device creates a first group, and the members of the first group include the first application of the first device.

[0549] 2202. The second device sends a first request to the first device. The first request is used to apply to join the second application of the second device into the first group created by the first device, and the members of the first group include the first application of the first device and the second application of the second device.

[0550] 2203. The first device receives the first request from the second device. The first request is used to apply to join the second application of the second device into the first group.

[0551] 2204. The first device adds the second application of the second device to the first group.

[0552] 2205. The first device migrates the first function in the first application to the second application of the second device, and the second function includes one or more UIs.

[0553] 2206. The second device receives a first function in the first application from the first device, where the first function includes one or more UIs.

[0554] ​ In the embodiments, the first device or the second device may be, respectively, mobile phone A and mobile phone B in the foregoing embodiments, and the first request may be an authentication request message in the above embodiments. ​ For parts not described in detail in the embodiments, reference may be made to the foregoing embodiments, and details are not described herein again.

[0555] Some other embodiments of the present application provide a first device or a second device, which may be the electronic device 200 as shown in ​ . The first device or the second device may include: a communication module, a memory, and one or more processors. The communication module and the memory are coupled to the processor. The memory is used to store computer program code, and the computer program code includes computer instructions.

[0556] Another embodiment of the present application provides a chip system, as shown in ​ . The chip system includes at least one processor 2301 and at least one interface circuit 2302. The processor 2301 and the interface circuit 2302 can be interconnected by a line. For example, the interface circuit 2302 can be used to receive signals from other devices (for example, the memory of an electronic device). For another example, the interface circuit 2302 can be used to send signals to other devices (for example, the processor 2301).

[0557] For example, the interface circuit 2302 can read instructions stored in the memory of the electronic device and send the instructions to the processor 2301. When the instructions are executed by the processor 2301, the first device / second device can execute the respective steps in the above embodiments.

[0558] For another example, the interface circuit 2302 can read instructions stored in the memory of the server and send the instructions to the processor 2301. When the instructions are executed by the processor 2301, the server can execute the respective steps in the above embodiments.

[0559] Of course, the chip system may also include other discrete devices, and the embodiments of the present application do not make specific limitations thereto.

[0560] Through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and simplicity of description, only the above division of each functional module is used for illustration. In practical applications, the above functions can be allocated to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

[0561] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

[0562] The units described as separate components may or may not be physically separated. The components displayed as units may be one physical unit or multiple physical units, that is, they can be located in one place, or they can be distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0563] In addition, in each embodiment of the present application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0564] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to enable a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, ROM, RAM, magnetic disks or optical discs that can store program codes.

[0565] The above content is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A function migration method, characterized in that, Applied to a communication system including a first device and a second device, the method includes: (1) The first device sends a first request to the second device, and the first request carries the identifier of the first device; (2) The second device receives the first request from the first device; (3) The second device sends a first response to the first device, and the first response is used to indicate a first group created by the second device, and the members of the first group include the second device; (4) The first device receives the first response from the second device; The first device sends a second request to the second device, and the second request is used to apply to add the first device to the first group; (5) The first device migrates a first function in a first application to the second device, the first application is any application in the first device, and the first function includes one or more graphical user interfaces UI.

2. The method according to claim 1, wherein the first response includes a personal identification number PIN corresponding to the first group and / or communication connection information of the second device, the first device sending a second request to the second device includes: sending the second request to the second device according to the PIN and / or the communication connection information of the second device; The method further includes: receiving a second response from the second device, and the second response is used to indicate that the first device has joined the first group.

3. The method according to claim 1 or 2, wherein in response to a first operation of the user, the first device displays a first pop-up window, and the first pop-up window includes the identifiers of one or more devices that have not been authenticated with the first device; the first device sending a first request to the second device includes: in response to a second operation of the user selecting the second device in the first pop-up window, sending the first request to the second device.

4. The method according to claim 1 or 2, characterized in that, The method further includes: the first device creates a second group, and the members of the second group include the first device and the second device.

5. The method according to claim 1 or 2, characterized in that, The method further includes: in response to a first operation of the user in a first application of the first device, the first device displays a first pop-up window, and the first pop-up window includes the identifiers of devices in the same network as the first device; the first device sending a first request to the second device includes: the first device sends the first request to the second device in response to a second operation of the user selecting the second device in the first pop-up window.

6. The method according to claim 5, wherein The devices in the same network as the first device include trusted devices and untrusted devices; among them, the trusted devices include devices that log in to the same account as the first device, devices that have undergone device-level authentication with the first device, or devices that have undergone application-level authentication with the first application of the first device; the untrusted devices include devices that do not log in to the same account as the first device, devices that have not undergone device-level authentication with the first device, or devices that have not undergone application-level authentication with the first application of the first device.

7. The method according to claim 1 or 2, characterized in that, The method further includes: The second device displays a QR code picture, and the QR code picture includes the personal identification number PIN corresponding to the first group and / or the communication connection information of the second device; The first device scans the QR code picture displayed by the second device; The first device sends a second request to the second device, including: The first device sends the second request to the second device according to the PIN and / or the communication connection information of the second device.

8. The method according to claim 1 or 2, characterized in that, The first device migrating the first function in the first application to the second device includes: Sending the service information of the first function to the second device; When the first application is a live broadcast application, the service information of the first function includes at least one of the video stream, audio stream, and barrage information of the live broadcast room of the first device; or When the first application is a photo-taking application, the service information of the first function includes the shooting preview screen or the menu bar information of the shooting interface; or When the first application is a KTV application, the service information of the first function includes at least one of the song name, lyrics, audio information of the song, video information of the song, and control interface of the song; or When the first application is a shopping application, the service information of the first function includes the commodity information in the shopping cart; or When the first application is an email application, the service information of the first function includes at least one of the subject, body, and attachment of the email.

9. A function migration system, characterized in that, Including a first device and a second device, the first device and the second device execute the method according to any one of claims 1-8.

10. A computer-readable medium, characterized in that, For storing one or more programs, wherein the one or more programs are configured to be executed by one or more processors, and the one or more programs include instructions for executing the method according to any one of claims 1-8.

Images