一种跨系统传输目标对象的方法及设备与流程

1.本技术实施例涉及电子技术领域，尤其涉及一种跨系统传输目标对象的方法及设备。


背景技术：

2.随着电脑与手机的进一步生态融合，手机上的安卓(android)应用程序可以通过虚拟化技术运行在windows操作系统上，使得用户可以便捷地在windows操作系统上使用android应用程序。
3.在windows操作系统运行了android应用程序的情况下，windows应用程序与android应用程序之间可能需要频繁地交互文件。其中，由于windows操作系统与android操作系统属于完全不同的两种系统，实现逻辑和包括的组件等也都不同，因而两者之间的文件交互过程也比较复杂。
4.在windows应用程序与android应用程序之间进行文件交互时，用户需要进行多步、复杂的操作，用户使用体验较差。例如，用户想要将windows资源管理器中的目标文件传输至android应用程序时，需要先将windows资源管理器中的目标文件放置在共享文件夹中，然后再通过在android应用程序中寻找并选择目标文件，或者通过从android文件管理中点击分享控件并选择目的android应用程序，从而实现该目标文件的传输。示例性的，关于文档1的文件传输过程可以参见图1a中的(a)-(f)，首先用户将windows应用程序的窗口01中的文档1拖拽至共享文件夹，然后用户打开android应用程序的窗口02，而后用户点击添加控件03后，选择共享文件夹，选择共享文件夹中的文档1，从而将文档1添加到android应用程序的窗口中，用户需要进行一系列的复杂操作。


技术实现要素：

5.本技术实施例提供一种跨系统传输目标对象的方法及设备，能够在第一操作系统上运行了第二操作系统的应用程序的情况下，基于用户的简单操作，实现第一操作系统的应用程序与第二操作系统的应用程序之间的文件或文本交互，以及第二操作系统的不同应用程序之间的文件或文本交互，且该操作更符合用户基于第一操作系统的使用习惯，用户使用体验较好。
6.为达到上述目的，本技术实施例采用如下技术方案：
7.一方面，本技术实施例提供了一种目标对象的传输方法，应用于电子设备，该电子设备运行有第一操作系统，第一操作系统上运行有第一操作系统的应用程序，且第一操作系统上基于模拟器运行有第二操作系统的应用程序。该方法包括：电子设备显示第一界面，第一界面包括第一应用程序的窗口和第二应用程序的窗口，第一应用程序的窗口中包括目标对象，第二应用程序的窗口中不包括目标对象。其中，第一应用程序或第二应用程序中的至少一个为第二操作系统的应用程序。电子设备响应于目标对象从第一应用程序的窗口拖拽至第二应用程序的窗口后释放拖拽的拖拽事件，将目标对象传输至第二应用程序。
8.例如，该拖拽事件可由用户的拖拽操作触发。这样，电子设备能够基于用户简单的拖拽操作，实现第一操作系统的应用程序与第二操作系统的应用程序之间的目标对象的交互，以及第一操作系统上第二操作系统的不同应用程序之间的目标对象的交互。并且，用户的该简单操作更符合用户基于第一操作系统的使用习惯，用户使用体验较好。例如，该目标对象可以包括文件、文本或其他可传输对象。
9.在一种可能的设计中，该方法还包括：电子设备响应于目标对象从第一应用程序的窗口拖拽至第二应用程序的窗口后释放拖拽的拖拽事件，显示第二界面，第二界面包括第一应用程序的窗口和第二应用程序的窗口，第二应用程序的窗口中包括目标对象。
10.也就是说，电子设备将目标对象将第一应用程序传输至第二应用程序的后，可以在第二应用程序的窗口中显示该目标对象。
11.在另一种可能的设计中，第一应用程序或第二应用程序中的一个为第二操作系统的应用程序，目标对象包括一个或多个文件，电子设备包括第一操作系统和第二操作系统的共享文件夹。电子设备将目标对象传输至第二应用程序，包括：电子设备基于共享文件夹，将目标对象传输至第二应用程序。
12.在该方案中，目标对象为目标文件，第一应用程序中的目标对象可以通过共享文件夹，传输至第二应用程序。
13.在另一种可能的设计中，第一应用程序为第一操作系统的应用程序，第二应用程序为第二操作系统的应用程序；第一操作系统为模拟器的主机端host，第二操作系统为模拟器的客户端guest。电子设备基于共享文件夹，将目标对象传输至第二应用程序，包括：主机端host将目标对象拷贝至共享文件夹；客户端guest从共享文件夹获取目标对象；客户端guest根据目标对象构建第二操作系统侧的拖拽事件，以将目标对象传输至第二应用程序。
14.在该方案中，基于共享文件夹，第一操作系统应用程序中的目标对象，可以被传输至第二操作系统的应用程序中。
15.在另一种可能的设计中，在主机端host将目标对象拷贝至共享文件夹之前，该方法还包括：主机端host基于管道通信通知客户端guest发生拖拽事件；主机端host在拖拽释放后，基于管道通信将拖拽释放位置坐标和拽释放窗口对应的第二操作系统侧窗口标识和传输类型通知给客户端guest；传输类型用于表示目标对象在第一操作系统的应用程序与第二操作系统的应用程序之间传输。若客户端guest根据拖拽释放位置坐标和拽释放窗口对应的第二操作系统侧窗口标识确定释放位置允许拖拽，则基于传输类型通过管道通信通知主机端host传输目标对象。主机端host将目标对象拷贝至共享文件夹，包括：主机端host将目标对象拷贝至共享文件夹，并基于管道通信将拷贝完成消息通知给客户端guest。客户端guest从共享文件夹获取目标对象，包括：客户端guest接收到拷贝完成消息后，从共享文件夹获取目标对象。
16.也就是说，第一操作系统和第二操作系统之间可以基于管道通信进行通信交互，从而将第一操作系统应用程序中的目标对象传输至第二操作系统的应用程序中。
17.在另一种可能的设计中，主机端host将目标对象拷贝至共享文件夹，并基于管道通信将拷贝完成消息通知给客户端guest，包括：主机端host每将目标对象中的单个文件拷贝至共享文件夹后，基于管道通信将拷贝完成消息通知给客户端guest。客户端guest从共享文件夹获取目标对象，包括：客户端guest每接收到一次拷贝完成消息后，从共享文件夹
获取目标对象的一个文件。客户端guest根据目标对象构建第二操作系统侧的拖拽事件，以将目标对象传输至第二应用程序，包括：客户端guest根据目标对象中的单个文件分别构建第二操作系统侧的拖拽事件，以将目标对象中的每个文件分别传输至第二应用程序。
18.在该方案中，当目标对象包括多个文件时，电子设备可以将目标文件中的单个文件分别传输至第二应用程序。
19.在另一种可能的设计中，拷贝完成消息包括拷贝完成的文件的文件名；或者，拷贝完成消息包括拷贝完成的文件的文件名信息和时间戳。
20.这样，客户端guest可以基于文件的文件名，以及时间戳，获取目标对象。
21.在另一种可能的设计中，该方法还包括：当拖拽位置进入第三应用程序的窗口后，第三应用程序为第二操作系统的应用程序，且第三应用程序与第二应用程序相同或不同，电子设备根据第三应用程序是否允许拖入目标对象，显示允许拖拽标识或禁止拖拽标识。
22.这样，电子设备可以通过显示允许拖拽标识或禁止拖拽标识，来实时提示用户当前位置是否允许拖入目标对象。
23.在另一种可能的设计中，第一应用程序为第二操作系统的应用程序，第二应用程序为第一操作系统的应用程序；第一操作系统为模拟器的主机端host，第二操作系统为模拟器的客户端guest。电子设备基于共享文件夹，将目标对象传输至第二应用程序，包括：主机端host构建第一操作系统侧的拖拽事件；客户端guest将目标对象拷贝至共享文件夹；主机端host取消第一操作系统侧的拖拽事件，将目标对象从共享文件夹，剪切至第二应用程序。
24.在该方案中，电子设备可以响应于用户的拖拽，并基于共享文件夹，将第二操作系统的应用程序中的目标对象剪切至第二应用程序。
25.在另一种可能的设计中，若第二应用程序为第一操作系统的资源管理器，则客户端guest将目标对象拷贝至共享文件夹，包括：客户端guest以单个文件为粒度，将目标对象中的每个文件分别拷贝至共享文件夹。主机端host从共享文件夹将目标对象，剪切至第二应用程序，包括：主机端host分别将目标对象中的每个文件从共享文件夹，剪切至第二应用程序。
26.在该方案中，当目标对象包括多个文件时，电子设备可以响应于用户的拖拽，并基于共享文件夹，将第二操作系统的应用程序中目标对象包括的单个文件分别剪切至第二应用程序。
27.在另一种可能的设计中，第一应用程序为第二操作系统的应用程序，第二应用程序为第一操作系统的应用程序；第一操作系统为模拟器的主机端host，第二操作系统为模拟器的客户端guest。电子设备基于共享文件夹，将目标对象传输至第二应用程序，包括：主机端host构建第一操作系统侧的拖拽事件；客户端guest将目标对象拷贝至共享文件夹；主机端host从共享文件夹获取目标对象；主机端host基于第一操作系统侧的拖拽事件，将目标对象传输至第二应用程序，并结束第一操作系统侧的拖拽事件。
28.在该方案中，电子设备基于共享文件夹和构建的拖拽事件，将第二操作系统的应用程序中的目标对象传输至第二应用程序。
29.在另一种可能的设计中，在客户端guest将目标对象拷贝至共享文件夹之前，该方法还包括：客户端guest基于管道通信通知主机端host发生拖拽事件；在拖拽释放后，若拖
拽释放窗口为第一操作系统应用程序的窗口，则主机端host基于管道通信将传输类型通知给客户端guest；传输类型用于表示目标对象在第一操作系统的应用程序与第二操作系统的应用程序之间传输；客户端guest接收到传输类型后，基于管道通信通知主机端guest传输目标对象。在客户端guest将目标对象拷贝至共享文件夹之后，该方法还包括：客户端guest将拷贝完成消息通知给主机端host。
30.在该方案中，第一操作系统和第二操作系统之间基于管道通信进行通信交互，从而将第二操作系统应用程序中的目标对象传输至第一操作系统的应用程序中。
31.在另一种可能的设计中，拷贝完成消息包括拷贝完成的文件的文件名；或者，拷贝完成消息包括拷贝完成的文件的文件名信息和时间戳。
32.这样，主机端可以基于文件的文件名，以及时间戳，获取目标对象。
33.在另一种可能的设计中，在客户端guest基于管道通信通知主机端host发生拖拽事件之后，该方法还包括：客户端guest基于管道通信将目标对象的文件名信息和拖拽图标通知给主机端host；主机端host根据文件名信息构建第一操作系统侧的拖拽事件，并设置拖拽图标。
34.这样，在用户拖拽目标对象的过程中，电子设备可以在界面上实时显示拖拽图标。
35.在另一种可能的设计中，第一应用程序和第二应用程序为第二操作系统的应用程序，目标对象包括一个或多个文件；电子设备将目标对象传输至第二应用程序，包括：电子设备基于管道通信，将目标对象传输至第二应用程序。
36.在该方案中，电子设备可以基于管道通信，将第二操作系统中第一应用程序中的目标对象，传输至第二应用程序。
37.在另一种可能的设计中，电子设备基于管道通信，将目标对象传输至第二应用程序，包括：客户端guest基于管道通信通知主机端host发生拖拽事件。主机端host构建第一操作系统侧的拖拽事件。在拖拽释放后，若主机端host根据释放位置坐标确定拖拽释放窗口为第二操作系统其他应用程序的窗口，则基于管道通信将拖拽源窗口对应的第二操作系统侧窗口标识、拖拽释放位置、拽释放窗口对应的第二操作系统侧窗口标识和传输类型通知给客户端guest。传输类型用于表示目标对象在第二操作系统的不同应用程序之间传输。若客户端guest根据拖拽释放位置和拽释放窗口对应的第二操作系统侧窗口标识确定释放位置允许拖拽，则基于管道通信通知主机端host传输目标对象。客户端guest获取目标对象，并根据目标对象构建第二操作系统侧拖拽事件，以将目标对象传输至第二应用程序。
38.在该方案中，电子设备可以基于构建的拖拽事件，在第二操作系统的不同应用程序之间传输目标对象。
39.在另一种可能的设计中，guest侧存储有目标对象的文件名信息。或者，客户端guest基于管道通信通知主机端host发生拖拽事件后，将目标对象的文件名信息通知给主机端host；在拖拽释放后，主机端host将文件名信息通知给客户端guest。客户端guest获取目标对象，包括：客户端guest根据文件名信息，获取目标对象。
40.也就是说，目标对象的文件名信息可以在第二操作系统和第一操作系统之间进行传递，或者第二操作系统可以预先进行存储，以便在拖拽释放后根据该文件名信息获取目标对象，从而传输至第二应用程序。
41.在另一种可能的设计中，该方法还包括：当拖拽位置进入第三应用程序的窗口后，
第三应用程序为第二操作系统的应用程序，且第三应用程序与第二应用程序相同或不同，电子设备根据第三应用程序是否允许拖入目标对象，显示允许拖拽标识或禁止拖拽标识。
42.这样，电子设备可以通过显示允许拖拽标识或禁止拖拽标识，来提示用户当前位置是否允许拖拽。
43.在另一种可能的设计中，在电子设备将将目标对象传输至第二应用程序之后，该方法还包括：电子设备将目标对象保存到第二应用程序的窗口内拖拽释放位置对应的目录下；或者，电子设备将目标对象通过第二应用程序发送给联系对象。
44.也就是说，第二应用程序可以保存传输获得的目标对象，或者将该目标对象发送给联系对象。
45.在另一种可能的设计中，拖拽事件为用户使用鼠标进行的拖拽操作触发的事件，或者用户基于触摸屏的拖拽操作触发的事件。
46.也就是说，用户可以通过鼠标，或者通过触摸屏的触摸操作，来拖拽传输目标对象。
47.在另一种可能的设计中，目标对象为目标文本，电子设备将目标对象传输至第二应用程序，包括：电子设备基于管道通信，将目标对象传输至第二应用程序。
48.在该方案中，响应于用户的拖拽操作，电子设备可以基于管道通信，将第一应用程序中的目标文件传输至第二应用程序。
49.在另一种可能的设计中，第一应用程序为第一操作系统的应用程序，第二应用程序为第二操作系统的应用程序。电子设备基于管道通信，将目标对象传输至第二应用程序，包括：主机端host基于管道通信通知客户端guest发生拖拽事件。主机端host在拖拽释放后，基于管道通信将拖拽释放位置坐标和拽释放窗口对应的第二操作系统侧窗口标识、传输类型和目标对象的文本内容通知给客户端guest；传输类型用于表示目标对象在第一操作系统的应用程序与第二操作系统的应用程序之间传输。若客户端guest根据拖拽释放位置坐标和拽释放窗口对应的第二操作系统侧窗口标识确定释放位置允许拖拽，则基于传输类型，根据文本内容构建第二操作系统侧拖拽事件，以将目标对象传输至第二应用程序。
50.在该方案中，电子设备可以基于管道通信和构建的第二操作系统侧的拖拽事件，将目标对象传输至第二操作系统的第二应用程序。
51.在另一种可能的设计中，第一应用程序为第二操作系统的应用程序，第二应用程序为第一操作系统的应用程序。电子设备基于管道通信，将目标对象传输至第二应用程序，包括：客户端guest基于管道通信通知主机端host发生拖拽事件，并将目标对象的文本内容通知给主机端host；主机端host构建第一操作系统侧拖拽事件。在拖拽释放后，若主机端host根据释放位置坐标确定拖拽释放窗口为第一操作系统应用程序的窗口，则基于管道通信将传输类型通知给客户端guest；传输类型用于表示目标对象在第一操作系统的应用程序与第二操作系统的应用程序之间传输。若拖拽释放窗口为第一操作系统的资源管理器窗口，则主机端host基于传输类型，取消第一操作系统侧拖拽事件，将目标对象剪切至第二应用程序。若拖拽释放窗口不是第一操作系统的资源管理器窗口，则主机端host基于传输类型，通过第二操作系统侧拖拽事件将目标对象传输至第二应用程序，并结束第一操作系统侧拖拽事件。
52.在该方案中，电子设备可以基于管道通信和构建的拖拽事件，将第二操作系统应
用程序中的目标对象，传输至第一操作系统的应用程序。
53.在另一种可能的设计中，第一应用程序和第二应用程序为第二操作系统的不同应用程序，电子设备基于管道通信，将目标对象传输至第二应用程序，包括：客户端guest基于管道通信通知主机端host发生拖拽事件，并将目标对象的文本内容通知给主机端host。主机端host构建第一操作系统侧的拖拽事件。在拖拽释放后，若主机端host根据释放位置坐标确定拖拽释放窗口为第二操作系统其他应用程序的窗口，则基于管道通信将拖拽源窗口对应的第二操作系统侧窗口标识、拖拽释放位置、拽释放窗口对应的第二操作系统侧窗口标识、传输类型和文本内容通知给客户端guest；传输类型用于表示目标对象在第二操作系统的不同应用程序之间传输。若客户端guest根据拖拽释放位置和拽释放窗口对应的第二操作系统侧窗口标识确定释放位置允许拖拽，则基于传输类型获取目标对象，根据目标对象构建第二操作系统侧拖拽事件，以将目标对象传输至第二应用程序。
54.在该方案中，电子设备可以基于管道通信和构建的拖拽事件，在第二操作系统的不同应用程序之间传输目标对象。
55.在另一种可能的设计中，guest侧存储有目标对象的文本内容；或者，客户端guest基于管道通信通知主机端host发生拖拽事件后，将目标对象的文本内容通知给主机端host；在拖拽释放后，主机端host将文本内容通知给客户端guest；客户端guest获取目标对象，包括：客户端guest获取文本内容。
56.也就是说，目标对象的文本内容可以在第二操作系统和第一操作系统之间进行传递，或者第二操作系统可以预先进行存储，以便在拖拽释放后将该文本内容传输至第二应用程序。
57.另一方面，本技术实施例提供了一种目标对象的传输方法，应用于电子设备，该电子设备运行有第一操作系统，第一操作系统上运行有第一操作系统的应用程序，且第一操作系统上基于模拟器运行有第二操作系统的应用程序。该方法包括：电子设备显示第一界面，第一界面包括第一应用程序的窗口和第二应用程序的窗口，第一应用程序的窗口中包括目标对象，第二应用程序的窗口中不包括目标对象；其中，第一应用程序和第二应用程序为不同操作系统中的应用程序，目标对象包括一个或多个文件。电子设备响应于针对第一应用程序的窗口中目标对象的目标事件，目标事件包括复制事件或剪切事件，以及第二应用程序的窗口中的粘贴事件，将目标对象传输至第二应用程序。
58.例如，该复制事件或剪切事件可由用户简单的目标操作而触发，例如该目标操作可以是复制操作或剪切操作等。这样，电子设备能够基于用户简单的目标操作，实现第一操作系统的应用程序与第二操作系统的应用程序之间的目标对象的交互，以及第一操作系统上第二操作系统的不同应用程序之间的目标对象的交互。并且，用户的该简单操作更符合用户基于第一操作系统的使用习惯，用户使用体验较好。例如，该目标对象可以包括文件、文本或其他可传输对象。
59.在一种可能的设计中，电子设备包括第一操作系统和第二操作系统的共享剪贴板和共享文件夹。电子设备响应于针对第一应用程序的窗口中目标对象的目标事件，以及第二应用程序的窗口中的粘贴事件，将目标对象传输至第二应用程序，包括：电子设备电子设备响应于针对第一应用程序的窗口中目标对象的目标事件，以及第二应用程序的窗口中的粘贴事件，基于共享剪贴板将目标对象传输至第二应用程序。
60.在该方案中，电子设备可以基于共享剪贴板，跨系统传输目标对象。
61.在另一种可能的设计中，第一应用程序为第一操作系统的应用程序，第二应用程序为第二操作系统的程序，第一操作系统为模拟器的主机端host，第二操作系统为模拟器的客户端guest；电子设备响应于针对第一应用程序的窗口中目标对象的目标事件，以及第二应用程序的窗口中的粘贴事件，将目标对象传输至第二应用程序，包括：主机端host响应于针对第一应用程序的窗口中目标对象的目标事件，将目标对象的路径信息存放到第一操作系统的剪贴板。主机端host将第一操作系统的剪贴板中的路径信息同步到共享剪贴板。客户端guest响应于第二应用程序的窗口中的粘贴事件，基于管道通信通知主机端host传输目标对象。主机端host将共享剪贴板中的路径信息对应的目标对象拷贝到共享文件夹，并将拷贝完成消息通知给客户端guest。客户端guest接收到拷贝完成消息后，将目标对象从共享文件夹复制到第二应用程序。
62.在该方案中，电子设备可以基于共享剪贴板，将目标对象从第一操作系统的应用程序传输至第二操作系统的应用程序。
63.在另一种可能的设计中，客户端guest基于管道通信通知主机端host传输目标对象，包括：客户端guest对第二应用程序对应的待粘贴目的路径，以及共享剪贴板中的路径信息对应的目标对象进行预检查，在预检查通过后基于管道通信通知主机端host传输目标对象。主机端host将共享剪贴板中的路径信息对应的目标对象拷贝到共享文件夹，包括：主机端host确定源目标对象是否存在，若存在则将共享剪贴板中的路径信息对应的目标对象拷贝到共享文件夹。
64.在该方案中，在目标对象的传输过程中，电子设备需要先进行相关的传输检查，在检查通过后，才能成功传输目标对象。
65.在另一种可能的设计中，第一应用程序为第二操作系统的应用程序，第二应用程序为第一操作系统的程序，第一操作系统为模拟器的主机端host，第二操作系统为模拟器的客户端guest。电子设备响应于针对第一应用程序的窗口中目标对象的目标事件，以及第二应用程序的窗口中的粘贴事件，将目标对象传输至第二应用程序，包括：客户端guest响应于针对第一应用程序的窗口中目标对象的目标事件，将目标对象的路径信息存放到第二操作系统的剪贴板。客户端guest将第二操作系统的剪贴板中的路径信息同步到共享剪贴板。主机端host响应于第二应用程序的窗口中的粘贴操作，基于管道通信通知客户端guest传输目标对象。客户端guest将共享剪贴板中的路径信息对应的目标对象拷贝到共享文件夹，并将拷贝完成消息通知给主机端host。主机端host接收到拷贝完成消息后，将目标对象从共享文件夹复制到第二应用程序。
66.在该方案中，电子设备可以基于共享剪贴板，将第二操作系统应用程序中的目标对象，传输至第一操作系统的应用程序。
67.在另一种可能的设计中，主机端host基于管道通信通知客户端guest传输目标对象，包括：主机端host对第二应用程序对应的待粘贴目的路径，以及共享剪贴板中的路径信息对应的目标对象进行预检查，在预检查通过后基于管道通信通知客户端guest传输目标对象。客户端guest将共享剪贴板中的路径信息对应的目标对象拷贝到共享文件夹，包括：客户端guest确定源目标对象是否存在，若存在则将共享剪贴板中的路径信息对应的目标对象拷贝到共享文件夹。
68.在该方案中，在目标对象的传输过程中，电子设备需要先进行相关的传输检查，在检查通过后，才能成功传输目标对象。
69.在另一种可能的设计中，在电子设备将将目标对象传输至第二应用程序之后，该方法还包括：电子设备将目标对象保存到第二应用程序的窗口内拖拽释放位置对应的目录下；或者，电子设备将目标对象通过第二应用程序发送给联系对象。
70.也就是说，第二应用程序可以保存传输获得的目标对象，或者将该目标对象发送给联系对象。
71.在另一种可能的设计中，目标事件为复制事件，复制事件由以下任意操作触发：用户针对目标对象使用键盘快捷键的复制操作，用户针对目标对象使用鼠标右键选择复制的操作，用户针对目标对象长按鼠标左键后选择复制的操作，或用户基于触摸屏长按目标对象后选择复制的操作。粘贴事件由以下任意操作触发：用户针对目标对象使用键盘快捷键的粘贴操作，用户针对目标对象使用鼠标右键选择粘贴的操作，用户针对目标对象长按鼠标左键后选择粘贴的操作，或用户基于触摸屏长按目标对象后选择粘贴的操作。
72.也就是说，电子设备可以响应于用户的复制操作和粘贴操作，将第一应用程序中的目标对象传输至第二应用程序，并保留第一应用程序中的目标对象。
73.在另一种可能的设计中，目标事件为剪切事件，在电子设备将目标对象传输至第二应用程序之后，该方法还包括：电子设备删除第一应用程序中的目标对象。
74.也就是说，电子设备可以响应于用户的剪切操作和粘贴操作，将第一应用程序中的目标对象传输至第二应用程序，并删除第一应用程序中的目标对象。
75.在另一种可能的设计中，共享文件夹为virtio-9p共享文件夹，管道通信为qemu pipe。
76.这样，第一应用程序和第二应用程序之间可以基于virtio-9p共享文件夹和qemu pipe，来传输目标对象。
77.在另一种可能的设计中，第一操作系统为windows操作系统，第二操作系统为安卓android操作系统。
78.这样，windows操作系统和android操作系统的应用程序之间可以跨系统传输目标对象，或者android操作系统的不同应用程序之间可以传输目标对象。
79.又一方面，本技术实施例提供了一种目标对象传输装置，该装置包含在电子设备中，该装置具有实现上述方面及可能的设计中任一方法中电子设备行为的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括至少一个与上述功能相对应的模块或单元。例如，显示模块或单元、传输模块或单元和处理模块或单元等。
80.另一方面，本技术实施例提供了一种电子设备，该电子设备可以包括屏幕，用于显示界面；一个或多个处理器；存储器；以及一个或多个计算机程序；其中，一个或多个计算机程序被存储在存储器中，一个或多个计算机程序包括指令；当指令被处理器执行时，使得电子设备执行上述方面任一项可能的设计中的目标对象的传输方法。
81.又一方面，本技术实施例提供了一种电子设备，该电子设备可以包括一个或多个处理器；存储器；以及一个或多个计算机程序；其中，一个或多个计算机程序被存储在存储器中，一个或多个计算机程序包括指令；当指令被处理器执行时，使得电子设备执行上述方面任一项可能的设计中的目标对象的传输方法。
82.另一方面，本技术实施例提供了一种计算机可读存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行上述方面任一项可能的设计中的目标对象的传输方法。
83.又一方面，本技术实施例提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行上述方面任一项可能的设计中的目标对象的传输方法。
84.本技术其他方面的有益效果可以参见上述方法方面有益效果的相关描述，不予赘述。
附图说明
85.图1a为现有技术提供的一种跨系统文件传输过程界面示意图；
86.图1b为现有技术提供的一种跨系统文件传输过程示意图；
87.图2为本技术实施例提供的一种目标对象的传输架构示意图；
88.图3为本技术实施例提供的一种电子设备的结构示意图；
89.图4为本技术实施例提供的另一种目标对象的传输架构示意图；
90.图5为本技术实施例提供的一组界面示意图；
91.图6a为本技术实施例提供的一种目标对象的传输过程示意图；
92.图6b为本技术实施例提供的一种目标对象的传输流程图；
93.图6c为本技术实施例提供的另一种目标对象的传输流程图；
94.图7a为本技术实施例提供的一组拖拽传输文件的界面示意图；
95.图7b为本技术实施例提供的另一组拖拽传输文件的界面示意图；
96.图7c为本技术实施例提供的一组拖拽传输文本的界面示意图；
97.图8a为本技术实施例提供的一种目标对象的传输过程示意图；
98.图8b为本技术实施例提供的一种目标对象的传输流程图；
99.图8c为本技术实施例提供的另一种目标对象的传输流程图；
100.图9为本技术实施例提供的一组拖拽传输文件的界面示意图；
101.图10为本技术实施例提供的一组确定目的端为windows资源管理器的流程图；
102.图11a为本技术实施例提供的一种目标对象的传输过程示意图；
103.图11b为本技术实施例提供的一种目标对象的传输流程图；
104.图11c为本技术实施例提供的另一种目标对象的传输流程图；
105.图12为本技术实施例提供的一组拖拽传输文件的界面示意图；
106.图13a为本技术实施例提供的一种目标对象的传输流程图；
107.图13b为本技术实施例提供的另一种目标对象的传输流程图；
108.图14为本技术实施例提供的一组复制文件的界面示意图；
109.图15为本技术实施例提供的一组剪切文件的界面示意图；
110.图16为本技术实施例提供的一组复制文本的界面示意图；
111.图17为本技术实施例提供的一种目标对象的传输流程图；
112.图18为本技术实施例提供的一组复制文件的界面示意图；
113.图19为本技术实施例提供的一种目标对象的传输流程图；
114.图20为本技术实施例提供的一组复制文件的界面示意图。
具体实施方式
115.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。其中，在本技术实施例的描述中，除非另有说明，“/”表示或的意思，例如，a/b可以表示a或b；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，在本技术实施例的描述中，“多个”是指两个或多于两个。
116.以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
117.在本技术实施例中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本技术实施例中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念。
118.目前，android应用程序可以基于android模拟器等虚拟化技术运行在windows操作系统上。windows操作系统与android应用程序之间交互文件的过程中，需要用户进行多步、复杂的操作，用户使用体验较差。
119.并且，如图1b所示，android侧与windows侧之间的文件传输，可通过安卓调试桥(android debug bridge，adb)工具来实现。其中，通过adb进行文件传输的本质是基于socket的tcp/ip通信，受带宽、网络延时等因素的限制，文件传输速度较慢；且文件传输依赖adb进程，一旦adb端口被占用或者adb未成功运行，则android侧与windows侧之间的通信就会断开，文件无法成功传输。
120.本技术实施例提供了一种跨系统传输目标对象的方法，可以应用于电子设备。参见图2所示的传输架构示意图，该电子设备上运行有第一操作系统，第一操作系统上基于模拟器运行有第二操作系统的应用程序。在该方法中，电子设备能够基于用户的简单操作，实现第一操作系统的应用程序与第二操作系统的应用程序之间的目标对象的交互，以及第一操作系统上第二操作系统的不同应用程序之间的目标对象的交互。其中，该目标对象可以包括文件、文本或其他可传输对象。并且，用户的该简单操作更符合用户基于第一操作系统的使用习惯，用户使用体验较好。例如，用户的简单操作可以为一步拖拽操作，或者用户的简单操作可以为复制/剪切操作和粘贴操作等。
121.此外，本技术实施例提供的方法不依赖adb、socket通信和网络能力等因素，不会受到这些因素的限制，因而文件传输速度快且安全可靠。
122.其中，第一操作系统和第二操作系统为不同的操作系统。例如，第一操作系统可以为windows操作系统、linux操作系统、unix操作系统、dos操作系统或mac os操作系统等；第二操作系统可以为android操作系统，ios操作系统，鸿蒙harmony操作系统，塞班symbian操作系统，黑莓lackberry操作系统，windows mobile操作系统，或palm操作系统等。本技术实施例对第一操作系统和第二操作系统的具体类型不予限定。
123.针对不同的第一操作系统和第二操作系统，用户的操作习惯也可能不同。例如，第一操作系统为windows操作系统，对于运行有windows操作系统的电脑等设备，用户通常习
惯使用鼠标或快捷键等方式进行文件传输。再例如，第二操作系统为android操作系统，对于运行有windows操作系统的手机等设备，用户通常不使用鼠标或快捷键等方式进行文件传输。
124.其中，图2所示的电子设备可以是台式电脑、笔记本电脑、桌面型电脑、超级移动个人计算机(ultra-mobile personal computer，umpc)或上网本等设备，本技术实施例对电子设备的具体类型不作任何限制。
125.在一些实施例中，该电子设备可以通过图3所示的计算机系统300来实现。计算机系统300包括显示屏30，至少一个处理器301，通信总线302，存储器303以及至少一个通信接口304。
126.显示屏30用于显示图像，视频等。显示屏30包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，lcd)，有机发光二极管(organic light-emitting diode，oled)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的，amoled)，柔性发光二极管(flex light-emitting diode，fled)，miniled，microled，micro-oled，量子点发光二极管(quantum dot light emitting diodes，qled)等。在本技术的实施例中，显示屏30可以用于显示多个窗口，包括第一操作系统的应用程序的窗口，和/或第二操作系统的应用程序的窗口等内容。
127.处理器301可以是一个通用中央处理器(central processing unit，cpu)，微处理器，特定应用集成电路(application specific integrated circuit，asic)，或一个或多个用于控制本技术方案程序执行的集成电路。处理器301可以运行第一操作系统，第一操作系统上可以基于模拟器运行第二操作系统的应用程序。
128.通信总线302可包括一通路，在上述组件之间传送信息。
129.通信接口304，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(radio access network，ran)，无线局域网(wireless local area networks，wlan)等。
130.存储器303可以是只读存储器(read-only memory，rom)或可存储静态信息和指令的其他类型的静态存储设备，ram或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、只读光盘(compact disc read-only memory，cd-rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
131.其中，存储器303用于存储执行本技术方案的应用程序代码，并由处理器301来控制执行。处理器301用于执行存储器303中存储的应用程序代码，以控制计算机系统300实现本技术下述实施例提供的文件交互方法，从而基于一步拖拽操作，或基于复制/剪切和粘贴操作等用户的简单操作，实现第一操作系统的应用程序与第二操作系统的应用程序之间，以及第二操作系统的不同应用程序之间的目标对象的交互。
132.可选的，本技术实施例中的计算机执行指令也可以称之为应用程序代码，本技术实施例对此不作具体限定。
133.在具体实现中，作为一种实施例，处理器301可以包括一个或多个cpu，例如图3中的cpu0和cpu1，每个cpu可以支持多个虚拟cpu，虚拟cpu又称vcpu。
134.在具体实现中，作为一种实施例，计算机系统300可以包括多个处理器，例如图3中的处理器301和处理器307。这些处理器中的每一个可以是一个单核(single-cpu)处理器，也可以是一个多核(multi-cpu)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
135.在具体实现中，作为一种实施例，计算机系统300还可以包括输出设备305和输入设备306。输出设备305和处理器301通信，可以以多种方式来显示信息。例如，输出设备305可以是液晶显示器(liquid crystal display，lcd)，发光二级管(light emitting diode，led)显示设备，阴极射线管(cathode ray tube，crt)显示设备，或投影仪(projector)等。输入设备306和处理器301通信，可以以多种方式接受用户的输入。例如，输入设备306可以是鼠标、键盘、触摸屏设备或传感设备等。
136.如前所述，电子设备上运行有第一操作系统，第一操作系统上运行有基于第一操作系统的应用程序(简称第一操作系统的应用程序)，第一操作系统上基于模拟器运行有第二操作系统的应用程序。电子设备可以采用多窗口的形式，运行第一操作系统的应用程序。在本技术的实施例中，第一操作系统侧的窗口与第二操作系统侧的窗口之间一一对应。这样，第二操作系统的应用程序也可以通过多窗口的形式运行在电子设备上。并且，基于该窗口间的对应关系，电子设备可以根据第一操作系统侧的窗口标识确定对应的第二操作系统侧的窗口，也可以根据第二操作系统侧的窗口标识确定对应的第一操作系统侧的窗口。
137.其中，继续参见图2，模拟器所运行的第一操作系统与第二操作系统之间可以基于管道通信技术进行通信交互，从而可以在第一操作系统的应用程序与第二操作系统的应用程序之间传输目标对象的过程中交互相关的信息，并在第二操作系统的不同应用程序之间传输目标对象的过程中交互相关的信息。通过如图2所示的共享文件夹技术，可以实现第一操作系统与第二操作系统之间共享目标对象。当第一操作系统的应用程序与第二操作系统的应用程序之间交互目标对象时，基于用户的简单操作，源端操作系统可以将待传输的目标对象自动存入共享文件夹，目的端操作系统可以自动从共享文件夹获取目标对象，并传输至目的应用程序的窗口。这样，结合第一操作系统与第二操作系统之间的管道通信以及共享文件夹技术，本技术实施例可以实现第一操作系统的应用程序与第二操作系统的应用程序之间的目标对象的交互，以及第一操作系统上运行的第二操作系统的不同应用程序之间的目标对象的交互。
138.其中，该目标对象可以包括文件、文本或其他可传输对象。例如，该文件可以是视频文件、音频文件、文档、图片、快捷方式或压缩文件等；该文本可以是一段文字、一段数字或一段字符串等。也就是说，结合第一操作系统与第二操作系统之间的管道通信以及共享文件夹技术，第一操作系统与第二操作系统之间可以进行信息交互并共享文件、文本或其他可传输对象，从而可以实现第一操作系统的应用程序与第二操作系统的应用程序之间交互文件、文本或其他可传输对象，并实现第一操作系统上运行的第二操作系统的不同应用程序之间交互文件、文本或其他可传输对象。
139.上述管道通信技术可以有多种，比如qemu管道通信(qemu pipe communication)，或称qemu pipe通信。该qemu pipe通信通过虚拟设备来实现第二操作系统与模拟器之间的
通信，通信速度快且稳定性高。在虚拟化领域中，存在模拟器的客户端(guest)侧与主机端(host)侧之间共享文件的用户需求。该共享文件夹技术可以通过多种技术来实现，例如基于virtio-i/o虚拟化框架的计划9共享文件夹(plan 9folder sharing over virtio-i/o virtualization framework，virtio-9p共享文件夹)(简称9p共享文件夹)、虚拟块设备(virtual block device，vbd)、网络文件系统(network file system，nfs)和公共互联网文件系统(common internet file system，cifs)、或虚拟机共享文件系统(shared file system for virtual machines，virtio-fs)技术等，不予限定。其中，virtio-9p利用现有的9p协议(一种网络文件系统协议)以及virtio驱动的架构，在qemu后端实现了一个服务器(server)端与具体的文件系统对接，真正实现guest与host间文件的共享及访问，故称之为virtio-9p。virtio-9p能够提供完备的功能支持和良好的性能。与virtio-9p相比，通过nfs、cifs在虚拟机与宿主机之间共享文件时，数据的传输需要经过多次拷贝，且增加了一层网络开销，性能上有较大损耗。加上网络文件系统并非专为虚拟化设计，所以其支持的功能也不够完善。
140.共享文件夹是打通安卓和windows数据的桥梁，模拟器安卓应用在传输文件的时候需要访问windows数据但无法直接获取，必须先调起安卓侧存储找到文件。此时在安卓侧存储中的第一个文件夹命名为“共享文件夹”，便于用户直接访问。对应的在windows侧本地创建一个共享文件夹，本质上和安卓侧存储内的文件夹是一个文件夹，需要用户把待传输的文件拖入windows侧的该文件夹后，安卓应用才能从安卓侧存储中找到该文件。
141.如图4所示，以下实施例中将以第一操作系统为windows操作系统，第二操作系统为android操作系统，电子设备上运行了windows操作系统，windows操作系统基于android模拟器运行有android应用程序，模拟器的host侧与guest侧之间采用采用qemu pipe通信，共享文件夹技术采用virtio-9p，且电子设备为电脑为例，对本技术实施例提供的跨系统传输目标对象的方法进行阐述。
142.其中，用于交互目标对象的android应用程序，可以是android操作系统的系统应用(例如android文件管理)，也可以是三方应用(例如社交类应用(比如微信、qq)、图库、新闻类应用、视频类应用(比如抖音、快手等)或游戏类应用)。用于目标对象的windows应用程序也可以是windows操作系统的系统应用(比如windows资源管理器、(文本编辑器)等)，或三方应用(比如浏览器应用、视频类应用或游戏类应用等)。本技术实施例对用于交互目标对象的android应用程序和windows应用程序的具体类型不予限定。
143.windows操作系统侧的窗口与android操作系统侧的窗口之间一一对应。这样，android应用程序可以通过多窗口的形式，运行在windows操作系统之上。基于该窗口对应关系，windows操作系统可以根据windows侧的窗口标识(例如为窗口句柄，或者窗口句柄对应的显示标识displayid)，确定对应的android侧的窗口标识(例如为android侧虚拟显示(virtualdisplay)窗口的displayid)；android操作系统也可以根据android侧的窗口标识，确定对应的windows侧的窗口标识。示例性的，windows侧的窗口标识为窗口句柄，android侧的窗口标识为虚拟显示(virtualdisplay)窗口displayid，该窗口对应关系为windows侧的窗口句柄与android侧的窗口displayid之间的一一对应关系。再示例性的，windows侧的窗口标识为窗口句柄对应的窗口displayid，android侧的窗口标识为窗口displayid，该窗口对应关系为windows侧的窗口displayid与android侧的窗口displayid
之间的一一对应关系。
144.例如，参见图5中的(a)，电脑桌面上包括多个windows应用程序的图标(比如windows资源管理器的图标51和网络连接图标52等)和android应用程序的图标(比如android(安卓)文件管理的图标53、新闻头条的图标54和社交软件的图标55等)。并且，屏幕上显示有windows资源管理器的窗口501。响应于用户针对android文件管理的图标502的操作，电脑运行android文件管理，并如图5中的(b)所示，在屏幕上也显示android文件管理的窗口503。
145.其中，windows操作系统也可以称为android模拟器的主机端(host)，android操作系统也可以称为android模拟器的客户端(guest)。由于android模拟器运行在windows操作系统之上，因而android模拟器可以理解为windows侧的应用程序。android模拟器与android应用程序之间的交互，也可以理解为android模拟器的host侧与guest侧之间的交互。
146.在本技术的实施例中，android模拟器与android操作系统之间(即android模拟器的host侧与guest侧之间)可以基于qemu pipe进行通信交互，从而可以在windows应用程序与android应用程序之间传输目标对象的过程中交互相关的信息，并在android不同应用程序之间传输目标对象的过程中交互相关的信息。这里“相关的信息”是指，除目标对象的数据内容以外，host侧与guest侧在目标对象的传输过程中交互的消息或信令等信息。通过9p共享文件夹技术可以实现windows操作系统与android操作系统之间共享目标对象。当windows操作系统的应用程序与android应用程序之间传输目标对象时，基于用户的简单操作，源端操作系统可以将待传输的目标对象自动存入9p共享文件夹，目的端操作系统可以自动从9p共享文件夹获取目标对象，并传输至目的应用程序的窗口。这样，结合android模拟器的host与guest之间的qemu pipe通信以及9p共享文件夹技术，本技术实施例可以实现windows应用程序与android应用程序之间的目标对象的交互，以及windows操作系统上不同android应用程序之间的目标对象的交互。
147.基于本技术实施例提供的方法，电脑能够基于用户的一步拖拽操作，或者用户的复制/剪切和粘贴操作等简单操作，实现android应用程序与windows应用程序之间交互目标对象，以及android不同应用程序之间交互目标对象。并且，用户触发交互目标对象的简单操作，符合用户基于windows操作系统的使用习惯，因而用户使用体验较好。
148.以下针对不同交互场景分别进行阐述。
149.场景(1)、一步拖拽实现windows应用程序到android应用程序的文件传输：
150.在该交互场景中，用户可以通过鼠标或触摸屏等输入设备，将电脑屏幕上显示的windows应用程序窗口中的目标对象，拖拽至android应用程序的窗口。电脑响应于用户的拖拽操作，将windows应用程序中的目标对象传输至android应用程序，实现windows应用程序到android应用程序的目标对象的复制。
151.在一些实施例中，在该交互场景中，参见图6a，android模拟器的host侧和guest侧之间基于qemu pipe进行通信交互。host侧产生windows侧拖拽事件(如对象连接与嵌入拖/放(object linking and embedding drag/drop，ole drag/drop)拖拽事件)后，将目标文件从windows应用程序传输至windows资源管理器，windows资源管理器将目标文件拷贝至9p共享文件夹。guest侧从9p共享文件夹读取该目标文件，获取目标文件的统一资源标识符
(uniform resource identifier，uri)，实现安卓内部目标文件的传输，从而将目标文件传输至android应用程序。
152.或者，在该交互场景下，参见图6a，android模拟器的host侧和guest侧之间基于qemu pipe进行通信交互，host侧产生windows侧拖拽事件(如ole drag/drop拖拽事件)后，基于qemu pipe将目标文本通知给guest侧。guest侧实现安卓内部目标文本的传输，从而将目标文本传输至android应用程序。
153.在另一些实施例中，在该交互场景中，参见图6b，本技术提供的跨系统传输目标对象的方法可以包括以下流程：目标对象由windows资源管理器等windows应用程序的窗口，拖拽进入安卓应用程序的窗口。循环执行以下步骤直至目标对象移出安卓应用程序的窗口或者目标对象被拖拽释放：安卓模拟器的host侧基于管道通信qemu pipe将拖入事件通知给guest侧(即安卓系统)，包括通知拖拽位置坐标、拖拽位置进入的安卓侧窗口标识和目标对象类型等信息，该目标对象类型用于表示拖拽的目标对象所属的类型，比如该目标对象类型可以为文件或文本等；guest侧基于qemu pipe向host侧回复是否允许拖入；host侧根据guest侧回复的是否允许拖入的信息显示拖拽样式(或称拖拽标识)，比如该拖拽样式包括禁止/允许拖拽标识等。在目标对象被释放后，host侧基于qemu pipe将拖拽释放事件通知给guest侧，包括通知拖拽释放位置对应的安卓侧窗口标识，拖拽释放位置坐标，目标对象类型，目标对象为目标文件时目标文件包括的文件数量和文件总大小，以及目标对象为目标文本时的文本长度和文本内容等信息。若guest侧确定拖拽释放位置允许拖拽，则构建空的拖拽开始事件。guest侧基于qemu pipe向host侧回复是否允许拖入。若host侧根据guest侧的回复确定不允许拖入，则host侧结束拖拽；若确定允许拖入，则执行后续流程。
154.若目标对象类型为文件，则参见图6b，循环执行以下步骤：host侧将目标文件中的单个文件依次拷贝至9p共享文件夹，并通知gue st侧单个文件拷贝完成；host侧获取单个文件的uri，通过uri读取文件，并构建单个文件的拖拽事件。参见图6b，host侧在目标文件的所有文件拷贝完成后通知guest侧；guest侧通过拖拽事件将目标文件传输至指定的拖拽释放目的安卓应用窗口。若目标对象类型为文本，则参见图6b，guest侧根据文本内容构建拖拽事件，将目标文本传输至指定的拖拽释放目的安卓应用窗口。而后，继续参见图6b，guest侧构建空的拖拽结束事件，从而结束目标对象的拖拽传输过程。其中，图6b中的可变(atler，alt)表示目标对象类型可改变，可以为“文件”，或者为“文本”。
155.在其他一些实施例中，结合图6c所示的流程图及图7a-图7c所示的界面示意图，对本技术提供的跨系统传输目标对象的方法进行详细说明：
156.601、host侧检测到windows应用程序窗口中的目标对象被触发拖拽。
157.比如，host侧检测到触发拖拽对应的鼠标事件，该鼠标事件用于表示从windows应用程序的窗口中开始拖拽目标对象。示例性的，如图7a中的(a)所示，用户通过鼠标选中windows资源管理器的窗口701中的目标对象(比如该目标对象包括文档1和文档2)，并开始拖拽该目标对象，此时host侧检测到触发拖拽对应的鼠标事件。
158.在拖拽开始后，host侧可以通过获取拖拽源窗口的窗口标识(比如句柄)，然后遍历维护的窗口标识的对应关系，若该对应关系中存在拖拽源窗口的窗口标识对应的窗口标识，则可以判断拖拽源窗口为android应用程序窗口；否则拖拽源窗口为windosws应用程序窗口。在步骤601中，拖拽源窗口为windows应用程序的窗口。
159.在拖拽过程中，host侧可以显示目标对象对应的拖拽图标，该拖拽图标由拖拽源窗口决定。示例性的，参见图7a中的(a)，在拖拽过程中，在鼠标的光标位置实时显示有拖拽图标702。
160.可选地，在拖拽过程中，电脑还可以提示用户当前拖拽位置是否允许拖入目标对象，该方法还可以包括步骤602-604：
161.602、若目标对象的拖拽位置进入android应用程序的窗口，则host侧基于qemu pipe将拖拽信息1通知给guest侧，该拖拽信息1包括拖拽位置坐标、拖拽位置对应的android侧窗口标识和目标对象类型。
162.其中，拖拽位置是指目标对象在拖拽过程中所处的位置。具体的，android应用程序窗口注册为ole drag/drop拖拽窗口，当有ole drag/drop拖拽事件进入android应用窗口后，会触发idroptarget::dragenter()接口，通过该接口可获知目标对象的拖拽位置进入了android应用程序的窗口。目标对象的拖拽位置进入android应用程序的窗口后，host侧通知guest侧发生拖拽事件(或发生拖入事件)。
163.host侧可以将拖拽信息1通知给guest侧。例如，host侧可以将目标对象类型通知给guest侧，以便guest侧获知待传输目标对象的类型，并确定拖拽位置或释放位置是否允许拖入该类型的目标对象。该目标对象类型可以包括文件或文本等可传输对象。比如，目标文本通过qemu pipe可以实现跨系统传输，而目标文件需要通过9p共享文件夹进行中转才能实现跨系统传输。
164.host侧还可以将拖拽位置对应的android侧窗口标识通知给guest侧，以便guest侧确定拖拽位置对应的android应用程序是否允许拖入目标对象。
165.host侧还可以将拖拽位置坐标通知给guest侧，以便guest侧的android应用程序确定当前拖拽位置是否允许拖入目标对象。
166.此外，拖拽信息1还可以包括本次拖拽的其他相关信息，这里不予限定。
167.603、guest侧根据拖拽信息1判断拖拽位置对应的android侧窗口和拖拽位置是否允许拖入该目标对象类型对应的目标对象，并基于qemu pipe将判断结果通知给host侧。
168.guest侧可以根据拖拽位置坐标、拖拽位置对应的android侧的窗口标识，以及拖拽进入的android侧窗口对应的android应用程序自身的处理逻辑，判断该android侧窗口内的当前拖拽位置是否允许拖入目标对象。
169.604、host侧根据guest侧通知的判断结果，提示用户当前android侧窗口中的拖拽位置是否允许拖入目标对象。
170.在一些实施例中，host侧将来自guest侧的判断结果通知给拖拽源窗口，源窗口通过相应的逻辑改变拖拽图标的状态，从而提示用户当前android侧窗口中的拖拽位置是否允许拖入目标对象。
171.在另一些实施例中，若拖拽位置所在的android侧窗口不允许拖入目标对象，则电脑可以通过显示禁止拖拽标识来提示用户；若拖拽位置所在的android侧窗口允许拖入目标对象，则电脑不显示禁止拖拽标识。示例性的，禁止拖拽标识可以参见图7a中的(a)所示的标识703。
172.在另一些实施例中，若拖拽位置所在的android侧窗口不允许拖入目标对象，则电脑可以显示禁止拖拽标识来提示用户；若拖拽位置所在的android侧窗口允许拖入目标对
象，则电脑可以显示允许拖拽标识来提示用户。
173.这样，基于禁止/允许拖拽标识，用户根据该标识可以直观地获知，是否可以在当前android侧窗口中的当前拖拽位置释放目标对象。
174.当拖拽位置在android应用程序的窗口内移动时会触发idroptarget::dragover()接口，通过该接口可获知拖拽位置当前正在android应用程序的窗口内移动。host侧基于qemu pipe将移动后的实时的拖拽位置坐标通知给guest侧。guest侧判断当前拖拽位置是否允许拖入目标对象，并基于qemu pipe将判断结果通知给host侧。host侧根据guest侧通知的判断结果，提示用户当前拖拽位置是否允许拖入目标对象。
175.另外，若拖拽位置离开android应用程序窗口则会触发idroptarget::dragleave()接口，通过该接口可获知拖拽位置已经移出android应用程序的窗口。
176.此外，若拖拽位置进入其他windows应用程序的窗口，则host侧按照windows操作系统的拖拽流程进行处理。
177.605、在host侧检测到拖拽的目标对象被释放后，若拖拽释放窗口为android应用程序的窗口，则host侧基于qemu pipe将拖拽信息2通知给guest侧，该拖拽信息2包括拖拽释放位置坐标、拖拽释放窗口对应的android侧窗口标识、目标对象类型和传输类型。
178.比如，host侧检测到释放对应的鼠标事件，该鼠标事件用于表示拖拽的目标对象被释放。示例性的，参见图7a中的(b)，用户通过鼠标将目标对象拖入android文件管理窗口704后，通过鼠标释放拖拽的目标对象，此时host侧检测到释放对应的鼠标事件。
179.在用户释放拖拽的目标对象后，host侧可以基于qemu pipe将拖拽释放事件通知给guest侧。其中，host侧可以将拖拽信息2通知给guest侧。该拖拽信息2可以包括拖拽释放位置坐标、拖拽释放窗口对应的android侧窗口标识、目标对象类型和传输类型。该拖拽信息2还可以包括拖拽相关的其他信息，比如当目标对象为目标文件时还包括文件数量，文件总大小；当目标文件为目标文本时还包括文本内容或文本长度等信息。本技术实施例对拖拽信息2的具体内容不于限定。其中，文本数量可以用于在拖拽传输过程中，提示用户总共拖拽几个文件，当前正在传输第几个文件等信息。文件总大小可以用于在拖拽传输过程中提示用户当前的传输进度。文本长度可以用于目的端将该文本长度与传输获取的文本内容的实际长度进行对比，以确认是否正确接收到拖拽传输的文本内容。
180.需要说明的是，当目标对象为目标文本时，host侧可以在拖拽进入安卓应用程序窗口后，将目标文本(即文本内容)传输给guest侧；也可以在获知guest侧允许拖入后，将目标文本传输给guest侧；也可以在拖拽释放在安卓应用程序窗口后，将目标文本传输给guest侧；或者，host侧也可以在其他时机将目标文本传输给guest侧，不予限定。
181.其中，传输类型包括windows应用程序与android应用程序之间的传输，或者android应用程序之间的传输等。guest侧可以根据具体的传输类型，对目标对象进行相应的传输处理。
182.当拖拽位置在android应用程序的窗口中释放时会触发idroptarget::drop()接口，通过该接口可获知所拖拽的目标对象在android应用程序的窗口内释放。
183.在步骤605中，若拖拽释放窗口为android应用程序的窗口，则由于拖拽源窗口为windows应用程序的窗口，因而该传输类型为windows应用程序与android应用程序之间的传输。
184.其中，当目标对象类型为文件时，目标对象为目标文件，用户释放拖拽的目标文件后，host侧还可以基于qemu pipe将目标文件的文件名、目标文件的总大小和目标文件包括的文件数量等信息通知给guest侧，以便guest侧的拖拽目的端获知待传输目标文件的其他相关信息。当目标对象类型为文本时，目标对象为目标文本，host侧还可以基于qemu pipe将目标文本的长度等信息通知给guest侧。
185.在其他一些实施例中，目标文件的文件名、目标文件的总大小和目标文件包括的文件数量，或文本长度等信息，也可以在拖拽释放前，在拖拽位置刚进入android应用程序的窗口后，由host侧通知给guest侧；或者，还可以在其他时机由host侧通知给guest侧，不予限定。
186.而后，若目标对象类型为文件，则执行步骤606-609；若目标对象类型为文本，则执行步骤610-611。
187.606、guest侧根据拖拽信息2判断拖拽释放窗口及释放位置是否允许拖入目标对象，若允许拖入则构建空的拖拽开始事件。
188.guest侧可以根据拖拽释放窗口对应的android侧窗口标识，确定拖拽释放的android应用程序的窗口是否允许拖入目标对象类型对应的目标对象。guest侧可以根据拖拽释放位置坐标，确定释放位置是否允许拖入目标对象类型对应的目标对象。
189.若允许拖入，则guest侧构建空的拖拽开始事件。构建空的拖拽开始事件是为了获取拖拽起始坐标所在的窗口。拖拽过程中，如果窗口变化了，会把拖拽开始保存的窗口赋值给拖拽事件，拖拽事件响应的还是拖拽开始的窗口，更加符合用户的预期。
190.guest侧还可以根据拖拽信息2确定传输类型为windows应用程序与android应用程序之间的传输，从而执行相应的传输流程。
191.此外，当目标对象类型为文件时，guest侧还可以根据目标文件的总大小，判断android系统所剩磁盘空间是否大于目标文件的总大小，进行容量等检查。
192.607、若guest侧确定允许拖入目标对象，且目标对象为目标文件，则guest侧基于qemu pipe通知host侧允许拖入并通知host侧传输目标文件。
193.若guest侧确定拖拽释放的android应用程序的窗口及释放位置允许拖入目标对象，目标对象为目标文件，且android系统所剩磁盘空间大于或者等于目标文件的文件总大小，则guest侧构建空的拖拽开始事件，用于标志此次拖拽事件的开始。并且，guest侧通知host侧开始传输目标文件。需要说明的是，在本技术实施例中，在目标对象的传输过程中，host侧与guest侧之间的通信交互通过qemu pipe来实现，不予一一说明。
194.若guest侧确定拖拽释放的android应用程序的窗口或释放位置不允许拖入目标对象，则host侧通知源窗口结束本次拖拽。
195.608、host侧将目标文件拷贝至9p共享文件夹，基于qemu pipe将目标文件的文件名信息通知给guest侧，并在目标文件拷贝完成后通知guest侧。
196.609、guest侧根据目标文件的文件名信息，从9p共享文件夹中获取目标文件，并根据目标文件构建android侧拖拽事件，实现目标文件到目的端android应用程序的传输。
197.guest侧从9p共享文件夹中读取目标文件后，根据目标文件的数据构建android侧的拖拽事件。其中，android系统的媒体库是一个数据库文件，当系统启动完成或者收到相关广播消息时，android系统会扫描文件系统中的数据，将新增和删除的文件信息更新到媒
体库中。应用程序可以通过uri从媒体库中读取文件系统中的文件信息。host侧将目标文件拷贝至9p共享文件夹中后，会通知guest侧目标文件的文件名，guest侧根据文件名和9p共享文件夹的路径可读取到该目标文件。在一些方案中，guest侧将该目标文件添加至媒体库，获取该目标文件对应的uri，之后就可以通过uri去媒体库中快速读取该目标文件，并根据该目标文件构建拖拽事件。
198.guest侧将拖拽事件下发给目的端android应用程序和释放位置，这样可以模拟android操作系统的拖拽传输，实现目标文件到目的android应用程序及释放位置的传输，从而实现目标文件从windows应用程序到android应用程序的传输。
199.在一些实施例中，在上述步骤608中，host侧可以将文件名信息和时间戳信息通知给guest侧。该时间戳信息用于标记不同时间对应的不同次拖拽的文件。这样，即便多次拖拽的目标文件有相同的文件名，目的端也可以基于该时间戳信息准确地获取到每次拖拽分别对应的文件内容，而不会出现本次拖拽的文件被上一次拖拽的重名文件所覆盖的情况。
200.其中，在步骤608-609的一种技术方案中，当一次拖拽的目标文件包括多个文件时，host侧拷贝完目标文件中的全部文件至9p共享文件夹后，通知guest侧拷贝完成。guest侧从9p共享文件夹中读取拷贝完成的目标文件，并构建android侧拖拽事件，实现9p共享文件夹至android应用程序的目标文件的传输。
201.在步骤608-609的另一种技术方案中，当一次拖拽的目标文件包括多个文件时，host侧每拷贝完一个文件至9p共享文件夹，就通知guest侧该单个文件拷贝完成。guest侧从9p共享文件夹中读取拷贝完成的该文件，并构建android侧拖拽事件，实现9p共享文件夹至android应用程序的目标文件的传输。
202.在该方案中，host侧每拷贝完一个文件都将该单个文件的文件名信息通知guest侧，guest侧根据文件名和9p共享文件夹的路径可读取到该单个文件，然后将该单个文件添加至媒体库，获取该文件对应的uri，之后就可以通过uri去媒体库中快速读取该单个文件，并构建单个文件的拖拽事件。guest侧将该拖拽事件下发给目的端应用程序及释放位置，从而将单个文件传输至目的应用程序的拖拽释放位置。host侧待一次拖拽所有目标文件拷贝完成后，通知guest侧。
203.基于该方案，host侧每拷贝完一个文件，guest侧就可以及时获取到该文件并构建android侧拖拽事件，而不用等到目标文件中的全部文件都拷贝完成后再获取文件并传输，可以减少等待时延，提高文件传输效率。
204.其中，guest侧构建的拖拽事件(比如单个文件的拖拽事件)可以包括如下四个事件：拖拽开始事件dragevent.action_drag_started，拖拽在目标窗口中的位置事件dragevent.action_drag_location，拖拽释放事件dragevent.action_drop，以及拖拽结束事件dragevent.action_drag_ended。上述四个事件一次性地通知给目的窗口的释放位置，即可模拟一次完整的拖拽事件。
205.值得说明的是，原生android系统本身不会产生拖拽事件，需要应用程序进行处理，当鼠标点中或触摸文件一定时间后，android系统会回调onlongclick消息，通过调用接口startdrag()可以激活拖拽。在本技术实施例中，拖拽效果是通过windows侧的拖拽事件实现的，android侧不需要调用startdrag()方法，只需要host侧将dragevent拖拽事件通知给目的窗口的相应位置即可。
206.若目标对象类型为文本，则在用户释放拖拽的目标对象之后，该方法还包括：
207.610、在host侧检测到拖拽的目标对象被释放后，若目标对象为目标文本，则host侧基于qemu pipe将目标文本通知给guest侧。
208.由于目标文本的数据量相对于文件来说通常较小，因而在拖拽的目标文本被释放后，host侧可以基于qemu pipe将目标文本的文本内容通知给guest侧，而不用通过9p文件夹进行中转，因而传输速度更快。
209.如前所述，目标文本也可以在通知拖入事件时通知给guest侧，在获知guest侧允许拖入后通知给guest侧，或者在其他时机通知给guest侧。
210.在步骤605之后，该方法还包括：
211.611、若guest侧根据拖拽信息2判断拖拽释放窗口及释放位置允许拖入目标对象，则构建空的拖拽开始事件，并根据目标文本构建android侧拖拽事件，实现目标文本到目的端android应用程序的传输。
212.其中，该拖拽开始事件的数据为空；guest侧根据目标文本构建的android侧拖拽事件是根据数据“目标文本”构建的，数据不为空。
213.在另一些实施例中，若目标对象类型为文本，则作为步骤610-611的一种替换方案，在步骤605之后，该方法还包括：
214.若guest侧确定允许拖入目标对象，且目标对象为目标文本，则guest侧构建空的拖拽开始事件，并基于qemu pipe通知host侧允许拖入并请求传输目标文本。host侧基于qemu pipe将目标文本传输给guest侧。guest侧根据目标文本构建android侧拖拽事件，实现目标文本到目的端android应用程序的传输。
215.如图6c所示，在步骤609或步骤611之后，该方法还可以包括：
216.612、guest侧构建空的拖拽结束事件，目的端android应用程序根据目标对象和释放位置进行相应处理。
217.guest侧可以构建空的拖拽结束事件，表示本次目标对象的拖拽传输过程结束。并且，当目标对象传输至guest侧目的端android应用程序后，目的端android应用程序可以基于android操作系统的拖拽流程以及具体的释放位置，对目标对象进行相应的处理。比如，目标对象为目标文件，释放位置位于android文件管理的窗口，android文件管理将目标文件放在释放位置对应的目录下；再比如，释放位置位于android文件管理的窗口中某个文件夹所在的位置，则android文件管理将目标文件放在该文件夹对应的目录下；再比如，释放位置位于android社交应用窗口的信息编辑窗口内，android社交应用(例如微信或qq等)将目标文件发送给联系对象(比如其他联系人或其他设备)。比如，目标对象为目标文本，释放位置位于android社交应用窗口的信息编辑窗口内，android社交应用将目标文本发送给联系人；再比如，目标对象为目标文本，释放位置位于android文本编辑器的窗口内，android文本编辑器将目标文本插入到窗口内的拖拽释放位置。
218.示例性的，基于图7a中的(a)-(b)所示的用户将目标文件从windows资源管理器窗口到android文件管理窗口的拖拽操作，参见图7a中的(c)，android文件管理窗口704中添加了目标文件，即添加了文档1和文档2，实现了目标文件从windows资源管理器到android文件管理的复制。
219.在一些实施例中，当目标对象为目标文件时，在目标文件的传输过程中，host侧还
可以显示传输进度条。例如，该传输进度条为复制进度条，guest侧通知host侧开始传输目标文件后，复制进度条开始显示。在guest侧将目标文件传输到android应用程序后，复制进度条显示完成。示例性的，复制进度条可以参见图7a中的(d)所示的控件705。此外，在拖拽传输过程中，进度条还可以根据文件数量提示用户总共拖拽几个文件，当前正在传输第几个文件等信息。进度条还可以根据文件总大小，提示用户当前的传输进度。
220.需要说明的是，图7a是以windows应用程序为windows资源管理器，android应用程序为android文件管理为例进行说明的，当windows应用程序和android应用程序为其他应用程序时，仍可以采用以上实施例提供的方法，实现从windows应用程序到android应用程序的文件传输，此处不再一一举例。其中，当windows应用程序为windows资源管理器以外的其他windows应用程序时，该其他windows应用程序本身支持拖拽至其他应用程序，且可以通过调用ole drag/drop接口实现拖拽。
221.示例性的，目标对象为目标文件，windows应用程序为windows资源管理器，android应用程序为android社交应用，参见图7b中的(a)-(b)，用户将目标文件从windows资源管理器窗口拖拽到android社交应用窗口中的信息编辑窗口后，android社交应用窗口中添加了目标文件，且目标文件发送给了android社交应用的聊天界面中的联系人，实现了目标文件从windows资源管理器到android社交应用的复制。
222.再示例性的，目标对象为目标文本，参见图7c中的(a)，用户从windows应用程序1的窗口710中开始拖拽目标文本“鸿蒙操作系统是一款基于微内核的面向全场景的分布式操作系统”。用户将目标文本拖拽至android应用程序(如安卓社交应用)窗口720的信息编辑窗口后，释放拖拽的目标文本。基于图7c中的(a)所示的用户将目标文本从windows应用程序(如windows应用程序1)的窗口710到android应用程序(如android社交应用)的窗口720中信息编辑窗口的拖拽操作，参见图7c中的(b)，android应用程序的窗口中添加了目标文本，且目标文本发送给了聊天界面对应的联系人，实现了目标文本从windows应用程序到android应用程序的复制。可选地，如图7c中的(a)所示，在拖拽过程中还可以显示拖拽图标730。
223.需要说明的是，在场景(1)中，以上多个实施例中的部分或全部步骤(例如图6c所示流程中的部分步骤)，在不冲突的情况下，可以重新组合，从而构成新的实施例。本技术实施例对此不再具体说明。
224.可见，针对上述场景(1)，本技术实施例通过qemu pipe通信可以实现android模拟器host侧与guest侧之间进行通信交互，基于windows侧窗口标识与android侧窗口标识的一一对应关系，可以根据拖拽释放位置所在的windows侧窗口确定目的端android应用程序的窗口，并且通过virtio-9p实现windows侧与android侧的文件共享，通过qemu pipe实现windows侧与android侧的文本共享，从而实现android应用程序与windows应用程序之间拖拽传输文件或文本。
225.在图6a-图7c描述的方案中，基于用户将目标对象从源端windows应用程序的窗口，拖拽至目的端android应用程序的窗口的简单的一步拖拽操作，即可实现windows应用程序到android应用程序的目标对象的传输，而不用像现有技术那样需要用户进行多步、复杂的操作。并且，用户通过鼠标等输入设备在窗口间的拖拽操作，更符合用户基于windows操作系统和电脑的操作使用习惯，因而用户使用体验较好，能够增加产品的竞争力。而且，
该方案不需要像现有技术那样依赖adb、socket通信和网络能力等因素，不会受到这些因素的限制，因而文件传输速度快且安全可靠。
226.场景(2)、一步拖拽实现android应用程序到windows应用程序的文件传输：
227.在该交互场景中，用户可以通过鼠标或触摸屏等输入设备，将电脑屏幕上显示的android应用程序窗口中的目标对象，拖拽至windows应用程序的窗口中。电脑响应于用户的拖拽操作，将android应用程序中的目标对象传输至windows应用程序，实现android应用程序到windows应用程序的目标对象的复制。
228.在一些实施例中，在该交互场景下，参见图8a，拖拽源android应用程序触发拖拽目标文件，android模拟器的guest侧(即安卓系统)将目标文件拷贝至9p共享文件夹，然后通过qemu pipe通信通知host侧。host侧从9p共享文件夹中将目标文件剪切至拖拽释放的windows资源管理器。或者，host侧从9p共享文件夹读取该目标文件，并根据目标文件构建windows侧拖拽事件(如ole drag/drop拖拽事件)，将目标文件传输至windows资源管理器以外的其他windows应用程序。
229.或者，在该交互场景下，参见图8a，拖拽源android应用程序触发拖拽目标文本，guest侧基于qemu pipe将目标文本(即文本内容)通知给host侧。host侧构建windows侧拖拽事件(如ole drag/drop拖拽事件)，将目标文本传输至windows应用程序。
230.在另一些实施例中，在该交互场景下，参见图8b，本技术提供的跨系统传输目标对象的方法可以包括以下流程：拖拽源android应用程序触发拖拽，安卓模拟器guest侧(即android系统)基于管道通信qemu pipe向host侧通知拖拽事件，包括通知拖拽位置对应的安卓侧窗口标识，目标对象类型，当目标对象为目标文件时的文件名信息(比如文件名拼接)、文件总大小和文件数量，以及目标对象为目标文本时的文本长度和文本内容等信息。若目标对象类型为文件，则host侧构建windows侧拖拽事件(如ole drag/drop拖拽事件)。若拖拽释放的目的窗口为windows应用程序的窗口，则host侧还可以进行权限或容量等检查。host侧基于qemu pipe通知guest侧开始传输文件。guest侧将目标文件拷贝至9p共享文件夹。
231.而后，继续参见图8b，若拖拽释放的目的端为windows资源管理器，则guest侧基于qemu pipe依次将目标文件中单个文件的文件名称，以及文件索引(比如可以表示当前文件为目标文件中的第几个文件等)或文件大小等信息通知给host侧。host侧取消ole drag/drop拖拽事件，将目标文件中的单个文件依次剪切至windows资源管理器。或者，若拖拽释放的目的端为windows资源管理器以外的其他windows应用程序，则待所有文件传输至9p共享文件夹后，guest侧通知host侧所有文件拷贝完成，host侧结束windows侧拖拽事件，idropsource::querycontinuedrag()接口返回dragdrop_s_drop状态，标志当前拖拽结束。host侧响应于该拖拽结束事件，将目标文件传输至目的windows应用程序。
232.参见图8b，若目标对象类型为文本，则在guest侧通知host侧拖拽事件后，host侧构建windows侧拖拽事件。若拖拽释放的目的端为windows资源管理器，则host侧取消windows侧拖拽事件，并将目标文本剪切至windows资源管理器。若拖拽释放的目的端为windows资源管理器以外的其他windows应用程序，则host侧结束windows侧拖拽事件，host侧响应于该拖拽结束事件，将目标文本传输至目的windows应用程序。host侧通知guest侧结束拖拽。
233.在其他一些实施例中，结合图8c所示的流程图及图9所示的界面示意图，对本技术提供的跨系统传输目标对象的方法进行详细说明：
234.800、guest侧检测到android应用程序的窗口中的目标对象被触发拖拽，拖拽源android应用程序触发拖拽事件。
235.比如，guest侧检测到触发拖拽对应的鼠标事件，该鼠标事件用于表示从android应用程序的窗口中开始拖拽目标对象。示例性的，参见图9中的(a)，用户通过鼠标选中android文件管理的窗口901中的目标对象，即图片b，并开始拖拽该目标对象，此时guest侧检测到触发拖拽对应的该鼠标事件。
236.在开始拖拽后，host侧可以通过获取拖拽源窗口的窗口标识(比如句柄)，然后遍历维护的窗口标识的对应关系，若该对应关系中不存在拖拽源窗口的窗口标识对应的窗口标识，则可以判断拖拽源窗口为windows应用程序窗口；否则拖拽源窗口为android应用程序窗口。在步骤800中，拖拽源窗口为windows应用程序的窗口。
237.801、guest侧将拖拽信息3通知给host侧，该拖拽信息3包括拖拽源窗口对应的android侧窗口标识和目标对象类型。
238.拖拽源android应用触发拖拽事件后，guest侧可以将该拖拽事件通知给host侧。guest侧可以将拖拽信息3通知给host侧，该拖拽信息3可以包括拖拽源窗口对应的android侧窗口标识和目标对象类型，以便host侧获知拖拽源端和待传输的目标对象的具体类型。其中，该目标对象类型可以为文件或文本等。
239.此外，如果目标对象为目标文件，则该拖拽信息3还可以包括目标文件的总大小和目标文件包括的文件数量等信息。如果目标对象为目标文本，则该拖拽信息3还可以包括目标文本的长度或目标文本的内容等信息。
240.若目标对象为目标文本，则执行步骤804。可选地，如果目标对象为目标文件，则在步骤804之前还执行步骤802-803。
241.802、若目标对象为目标文件，则guest侧还将目标对象的文件名信息和拖拽图标通知给host侧。
242.该文件名信息用于表示待传输目标文件的文件名。当目标文件包括多个文件时，该文件名信息可以为文件名拼接信息，例如为1.txt|2.txt|3.txt。
243.803、host侧根据文件名信息构建windows侧拖拽事件，并设置拖拽图标。
244.例如，host侧可以根据文件名拼接信息构建windows侧的ole drag/drop拖拽事件。该拖拽事件可以指定拖拽图标。host侧可以在拖拽过程中跟随拖拽位置(例如拖拽过程中鼠标的光标所在位置)实时显示拖拽图标。该拖拽图标可以使得用户直观地获知当前正在拖拽文件以及当前的拖拽位置。
245.在一些实施例中，该拖拽图标可以用于表示目标文件的类型、目标文件包括的数量、目标文件的总大小、目标文件源端应用程序对应的图标或源端应用程序对应的操作系统等信息中的一种或多种。比如，该拖拽图标可以为目标文件包括的文件的缩略图。示例性的，参见图9中的(a)，在拖拽过程中，鼠标的光标位置实时显示有拖拽图标902，该拖拽图标902的右上角显示有数字2，表示拖拽的目标文件中包括2个文件。
246.如果目标对象的拖拽位置在android应用程序源窗口中移动，则显示禁止拖拽符号；如果拖拽在源窗口中释放，则结束本次拖拽事件。如果拖拽在windows应用程序的窗口
中释放，则执行图8c所示的后续步骤。如果拖拽在android应用程序非源窗口中释放，则可以执行图11c所示的步骤1104及其后续流程。
247.804、在host侧检测到拖拽的目标对象被释放后，若拖拽释放窗口为windows应用程序的窗口，则host侧基于qemu pipe将拖拽信息4通知给guest侧，该拖拽信息4包括传输类型。
248.比如，host侧检测到释放对应的鼠标事件，该鼠标事件用于表示拖拽的目标对象被释放。示例性的，参见图9中的(a)，用户通过鼠标将目标文件拖入windows资源管理器的窗口903后，通过鼠标释放拖拽的目标文件，此时host侧检测到释放对应的鼠标事件。
249.host侧可以通过windowfrompoint()函数获取拖拽释放位置对应的窗口标识(比如句柄)，然后遍历维护的对应关系，若该对应关系中存在拖拽源窗口的窗口标识对应的窗口标识，则可以判断拖拽释放窗口为android应用程序窗口；否则拖拽释放窗口为windosws应用程序窗口。此处，拖拽释放窗口为windows应用程序的窗口。
250.若拖拽释放窗口为windows应用程序的窗口，则host侧还可以通过该windows应用程序进行权限、容量等检查，以确定是否能够正常拖入目标对象。
251.由于拖拽源窗口为android应用程序的窗口，拖拽释放窗口为windows应用程序的窗口，因而该传输类型为android应用程序与windows应用程序之间的传输。host侧将拖拽信息4通知给guest侧，该拖拽信息4包括传输类型，以便guest侧根据该传输类型进行相应的传输处理。此外，拖拽信息4还可以包括拖拽相关的其他信息，不予限定。
252.此外，若拖拽释放窗口为windows应用程序的窗口，则host侧还可以进行拖拽权限或容量等检查。比如，有些文件需要管理员权限才可以拖拽。
253.如果目标对象为目标文件，则执行步骤805；如果目标对象为目标文本，则执行步骤811。
254.805、若目标对象为目标文件，则host侧基于qemu pipe通知guest侧传输目标文件。
255.806、guest侧将目标文件拷贝至9p共享文件夹，基于qemu pipe将目标文件的文件名信息通知给host侧，并在目标文件拷贝完成后通知host侧。而后，执行步骤807或步骤810。
256.其中，guest侧可以每拷贝完目标文件中的一个文件至9p共享文件夹后，就通知host侧单个文件拷贝完成；guest侧可以将单个文件的文件名信息，以及文件索引和文件大小等信息通知给host侧。或者，guest侧可以在整个目标文件都拷贝至9p共享文件夹后，再通知host侧拷贝完成，不予限定。guest侧可以将拷贝至9p共享文件夹中的文件的路径，通知给host侧。
257.807、若目的端windows应用程序为windows资源管理器，且目标对象为目标文件，则host侧取消构建的windows侧拖拽事件。
258.808、host侧根据目标文件的文件名信息，将9p共享文件夹中的目标文件剪切至拖拽释放位置对应的windows资源管理器路径下。
259.其中，host侧可以在每个文件拷贝完成后，将单个文件依次剪切指目的路径；也可以在目标文件拷贝完成后，将目标文件剪切至目的路径。
260.例如，拖拽释放位置对应的windows资源管理器路径可以为桌面、收藏夹或d：\资
料等。host侧可以根据释放位置的全局坐标，确定拖拽释放窗口为windows资源管理器，并确定具体的拖拽释放路径。其中，全局坐标是相对于整个屏幕的坐标，释放位置的全局坐标是指通过鼠标进行拖拽释放时，释放位置相对于屏幕的坐标。
261.比如，windows侧的窗口标识为句柄。参见图10，host侧可以根据获取的释放位置的全局坐标，获取释放位置所在的windows窗口的句柄。然后，host侧获取释放位置所在的windows窗口的父窗口句柄与类名，获取已打开的windows资源管理器信息。而后，host侧判断父窗口类名是否为shelldll_defview。若不是shelldll_defview，则拖拽释放窗口不是windows资源管理器；若是shelldll_defview，则继续判断父窗口的父窗口类名是否为worker或是progman。如果是worker或是progman，则说明拖拽释放路径为windows资源管理器中的桌面，则通过shgetspecialfolderpath函数获取桌面路径。如果不是worker或是progman，则枚举拖拽窗口父窗口句柄与所有打开的windows资源管理器比较，确定拖拽释放位置对应的windows资源管理器路径。
262.其中，若guest侧在步骤807中每拷贝完目标文件中的一个文件至9p共享文件夹后，就通知host侧拷贝完成，则host侧可以在步骤808中及时将拷贝完成的该文件剪切至拖拽释放位置对应的windows资源管理器路径下，而不用等到目标文件中的各文件都拷贝完成后再剪切，可以提高文件传输的速率。
263.在一些实施例中，如果目的端windows应用程序为windows资源管理器，则也可以通过构建windows侧拖拽事件来传输目标文件。其中，相较于windows拖拽事件，通过调用剪切文件的接口实现9p共享文件夹到windows资源管理器的文件传输速度更快。
264.在步骤804之后，若目的端为windows资源管理器以外的其他windows应用程序，则该方法还包括：
265.809、若目的端为windows资源管理器以外的其他windows应用程序，则guest侧基于qemu pipe将目标文件的文件名信息通知给host侧，并在目标文件拷贝完成后通知host侧所有拖拽文件拷贝完成。
266.810、host侧根据目标文件的文件名信息，从将9p共享文件夹中读取目标文件，根据目标文件构建windows侧拖拽事件(如ole drag/drop拖拽事件)，实现目标文件到windows应用程序的传输，并结束该windows侧拖拽事件。
267.在一些实施例中，与步骤608中类似，在步骤806和步骤809中，guest侧可以基于qemu pipe将目标文件的文件名信息和时间戳信息通知给host侧。
268.在一些实施例中，在目标文件的传输过程中，host侧还可以显示传输进度条。
269.如果目标对象为目标文本，则在步骤800中guest侧触发拖拽事件之后，该方法还包括以下步骤：
270.811、guest侧触发拖拽事件后，将目标文本通知给host侧。
271.812、host侧根据目标文本构建windows侧拖拽事件。而后，执行步骤813或步骤814。
272.在步骤804之后，该方法还可以包括：
273.813、若目的端为windows资源管理器，则host侧结束windows侧拖拽事件，将目标文本剪切至拖拽释放位置对应的windows资源管理器路径下，并通知guest侧结束拖拽。
274.814、若目的端为windows资源管理器以外的其他windows应用程序，则host侧通过
构建windows侧拖拽事件，实现目标文本到windows应用程序的传输，而后结束windows侧拖拽事件。
275.参见图8c，在步骤808、步骤810或步骤814之后，该方法还可以包括：
276.815、host侧windows应用程序根据目标对象和释放位置进行相应处理。
277.关于该步骤的说明可以参见上述步骤612中的相关描述。
278.示例性的，基于图9中的(a)所示的用户将目标文件从android文件管理窗口到windows资源管理器窗口的拖拽操作，参见图9中的(b)，windows资源管理器窗口中添加了目标文件，即添加了图标b，实现了目标文件从android文件管理到windows资源管理器的复制。
279.需要说明的是，在场景(2)中，以上多个实施例中的部分或全部步骤(例如图8c所示流程中的部分步骤)，在不冲突的情况下，可以重新组合，从而构成新的实施例。本技术实施例对此不再具体说明。
280.可见，针对上述场景(2)，本技术实施例通过qemu pipe通信可以实现android模拟器host侧与guest侧之间进行通信交互，基于windows侧窗口标识(比如句柄)与android侧窗口标识(比如virtualdisplay窗口的displayid)的一一对应关系，可以根据拖拽源位置所在的windows侧窗口确定源端android应用程序，并且通过virtio-9p可以实现android侧与windows侧的文件共享，通过qemu pipe可以实现android侧与windows侧的文本共享，进而实现windows应用程序与android应用程序之间拖拽传输文件或文本。
281.在图8a-图10描述的方案中，基于用户将目标对象从源端android应用程序的窗口，拖拽至目的端windows应用程序的窗口的简单的一步拖拽操作，即可实现android应用程序到windows应用程序的目标对象的传输，而不用像现有技术那样需要用户进行多步、复杂的操作。并且，用户通过鼠标等输入设备在窗口间的拖拽操作，更符合用户基于windows操作系统和电脑的操作使用习惯，因而用户使用体验较好，能够增加产品的竞争力。而且，该方案不需要像现有技术那样依赖adb、socket通信和网络能力等因素，不会受到这些因素的限制，因而文件传输速度快且安全可靠。
282.场景(3)、一步拖拽实现android应用程序间的文件传输：
283.在该交互场景中，用户可以通过鼠标或触摸屏等输入设备，将windows操作系统上运行的一个android应用程序窗口中的目标对象，拖拽至另一个android应用程序的窗口中。电脑响应于用户的拖拽操作，将windows操作系统上一个android应用程序中的目标对象传输到另一个android应用程序中，实现windows操作系统上不同android应用程序间的目标对象的复制。
284.在该交互场景中，参见图11a，host侧检测android应用程序窗口是否发生拖拽文件操作。若android应用程序窗口发生拖拽文件操作，则检测拖拽释放位置是否处于其他android应用程序窗口。若拖拽释放位置处于其他android应用程序窗口，则基于管道通信通知guest侧拖拽释放的安卓侧窗口标识以及拖拽文件的文件名信息等，guest侧通过拖拽的目标对象uri构建传输的数据，模拟源android应用程序向目的android应用程序的拖拽传输目标对象。
285.在另一些实施例中，在该交互场景下，参见图11b，本技术提供的传输目标对象的方法可以包括以下流程：拖拽源android应用程序触发拖拽，guest侧(即android系统)基于
管道通信qemu pipe向host侧通知拖拽事件，包括通知拖拽位置对应的安卓侧窗口标识，目标对象类型，当目标对象为目标文件时的文件名信息(比如文件名拼接)、文件总大小和文件数量，以及目标对象为目标文本时的文本长度和文本内容等信息。host侧构建windows侧拖拽事件(如ole drag/drop拖拽事件)。若拖拽在安卓应用程序的窗口内移动，则循环执行以下步骤直至目标对象移出安卓应用程序的窗口或者目标对象被拖拽释放：安卓模拟器的host侧基于管道通信qemu pipe将拖入事件通知给guest侧，包括通知拖拽位置坐标、拖拽位置进入的安卓侧窗口标识和目标对象类型等信息；guest侧基于qemu pipe向host侧回复是否允许拖入；host侧根据guest侧是否允许拖入的回复显示拖拽样式，比如禁止/允许拖拽标识。
286.而后，继续参见图11b，若拖拽释放的目的窗口为安卓应用程序窗口，则host侧取消windows侧的拖拽事件，通知guest侧传输类型为android应用程序间的传输，并将拖拽源/目的窗口对应的安卓侧窗口标识，拖拽释放位置坐标和目标对象类型等信息通知给guest侧。具体的，host侧可以获取拖拽释放全局坐标，并判断拖拽释放坐标是否位于android应用程序窗口，以及通过窗口句柄获取拖拽释放android应用程序虚拟显示(virtualdisplay)窗口的displayid。然后，host侧将转换后的android应用程序内部坐标、android应用程序display窗口的displayid，目标对象类型以及传输类型通过qemu pipe通信传递给guest侧。guest侧构建空的拖拽开始事件。guest侧根据目标文件的uri/文本内容构建拖拽事件，以将目标对象传输至指定的拖拽释放目的安卓应用窗口。guest侧构建空的拖拽结束事件，以结束本次针对目标对象的拖拽传输。
287.在其他一些实施例中，结合图11c所示的流程图及图12所示的界面示意图，对本技术提供的传输目标对象的方法进行详细说明：
288.1100、guest侧检测到android应用程序1窗口中的目标对象被触发拖拽，拖拽源android应用触发拖拽事件。
289.比如，guest侧检测到触发拖拽对应的鼠标事件，该鼠标事件用于表示从android应用程序1的窗口中开始拖拽目标对象。示例性的，如图12中的(a)所示，用户通过触摸屏选中android应用程序1(如android文件管理)的窗口1201中的目标对象，并通过手指触摸拖拽该目标对象，此时guest侧检测到触发拖拽对应的鼠标事件。
290.1101、guest侧将拖拽信息5通知给host侧，该拖拽信息5包括拖拽源窗口对应的android侧窗口标识和目标对象类型。
291.拖拽源android应用触发拖拽事件后，guest侧可以将该拖拽事件通知给host侧。guest侧可以将拖拽信息5通知给host侧。例如，该拖拽信息5可以包括拖拽源窗口对应的android侧窗口标识和目标对象类型，以便host侧获知拖拽源端和待传输的目标对象的具体类型。其中，该目标对象类型可以为文件或文本等。此外，该拖拽信息5还可以包括拖拽相关的其他信息，比如目标对象为目标文件时还包括目标文件的文件名信息(如文件名拼接信息)和文件总大小等，目标对象为目标文本时还包括文本内容等信息，本技术实施例对拖拽信息5的具体内容不予限定。
292.若目标对象为目标文本，则执行步骤1104；如果目标对象为目标文件，则在步骤1104之前还执行步骤1102-1103。
293.1102、若目标对象为目标文件，则guest侧将目标对象的文件名信息和拖拽图标通
知给host侧。
294.其中，若拖拽信息5中包括文件名信息，则步骤1102中也可以不包括文件名信息。
295.1103、host侧根据文件名信息构建windows侧的拖拽事件，并设置拖拽图标。
296.关于步骤1102-1103的描述可以参见上述步骤802-803中的说明，不予赘述。其中，host侧设置拖拽图标为可选操作。
297.如果目标对象的拖拽位置在android应用程序源窗口中移动，则显示禁止拖拽符号。如果拖拽在源窗口中释放，则结束本次拖拽事件。如果拖拽在windows应用程序的窗口中释放，则执行图8c所示的步骤804及其后续步骤。如果目标对象的拖拽位置在android应用程序非源窗口中移动，则host侧向guest侧通知通入事件，包括拖拽位置坐标、拖拽位置所在android侧窗口标识和目标类型等信息。guest侧向host侧回复当前拖拽进入的窗口和拖拽位置是否允许拖入。host侧根据该回复显示允许/禁止拖拽标识。如果拖拽在android应用程序非源窗口中释放，则执行图11c所示的后续步骤。
298.1104、在host侧检测到拖拽的目标对象被释放后，若host侧根据释放位置坐标确定拖拽释放窗口为android应用程序2的窗口，则取消windows侧拖拽事件，并基于qemu pipe将拖拽信息6通知给guest侧，该拖拽信息6包括拖拽源窗口对应的android侧窗口标识、拖拽释放窗口对应的android侧窗口标识、释放位置坐标、目标对象类型和传输类型。
299.比如，host侧检测到释放对应的鼠标事件，该鼠标事件用于表示拖拽的目标对象被释放。示例性的，参见图12中的(a)，用户通过鼠标在android应用程序2(如android社交应用)的窗口1202内释放拖拽的目标文件，此时host侧检测到释放对应的鼠标事件。
300.其中，host侧根据释放位置的坐标确定拖拽释放窗口为android应用程序2的窗口，并根据拖拽源窗口和拖拽释放窗口确定传输类型为android应用程序之间的传输。host侧将传输类型通知给guest侧，以便guest侧根据传输类型进行相应的传输处理。
301.host侧将拖拽释放窗口对应的android侧窗口标识、释放位置坐标、目标对象类型通知给guest侧，以便guest侧确定拖拽释放窗口对应的android侧窗口及释放位置是否允许拖入目标文件。
302.此外，如果目标对象为目标文件，则拖拽信息6还可以包括目标文件的总大小和目标文件包括的文件数量等信息。如果目标对象为目标文本，则拖拽信息6还可以包括目标文本的长度等信息。或者，guest侧也可以在触发拖拽事件后，将这些信息通知给host侧。
303.1105、guest侧判断拖拽释放窗口及释放位置是否允许拖入目标对象，并基于qemu pipe将判断结果通知给host侧。
304.若目标对象为目标文件，则执行步骤1106-1107；若目标对象为目标文本，则执行步骤1108-1111。
305.1106、若host侧根据来自guest侧的判断结果确定允许拖入，则基于qemu pipe将目标文件的文件名信息通知给guest侧。
306.可选地，host侧还可以根据来自guest侧的判断结果，显示允许/禁止拖拽标识。
307.可选地，在步骤1106中，与上述步骤608中类似，host侧还可以将时间戳信息通知给guest侧。
308.1107、guest侧首先构建空的拖拽开始事件，而后根据文件名信息获取目标文件，并根据目标文件构建android侧拖拽事件，实现目标文件到android应用程序2的传输，并构
建空的拖拽结束事件。
309.其中，guest侧根据文件名信息获取目标文件后，可以将目标文件文件添加至媒体库，获取目标文件对应的uri。而后，guest侧可以通过uri去媒体库中快速读取该目标文件，根据目标文件构建android侧拖拽事件。
310.或者，guest侧与host侧之间也可以不传递文件名信息，而传递目标文件的uri，从而根据uri获取目标文件，并根据目标文件构建android侧拖拽事件。
311.在一些实施例中，在目标文件的传输过程中，电脑还可以显示传输进度条。
312.在上述实施例中，guest侧和host侧通过传递目标文件的文件名信息来通知拖拽的目标文件。在其他一些实施例中，guest侧和host侧之间也可以不用传递目标文件的文件名信息，在android应用程序1触发拖拽后，guest侧可以保存拖拽的目标文件的标识信息；在拖拽释放到android应用程序2的窗口后，guest侧可以根据保存的目标文件的标识信息，获取目标文件，从而根据目标文件构建android侧拖拽事件。也就是说，在该场景中，host侧可以通知guest侧拖拽释放窗口为android应用程序窗口。至于目标文件的文件名或路径信息，可以guset侧触发拖拽的时候存储，也可以由host侧中转，将guest侧通知的文件名等拖拽信息在释放时再次传给android应用程序。
313.如果目标对象为目标文本，则在guest侧触发拖拽事件后，该方法还可以包括：
314.1108、guest侧触发拖拽事件后，若目标对象为目标文本，则将目标文本通知给host侧。
315.1109、host侧根据目标文本构建windows侧拖拽事件。
316.1110、在host侧检测到拖拽的目标对象被释放后，目标对象为目标文本，host侧将目标文本通知给guest侧。
317.在步骤1104之后，该方法还可以包括：
318.1111、若guest侧判断拖拽释放窗口及释放位置允许拖入目标对象，目标对象为目标文本，则首先构建空的拖拽开始事件，而后根据目标文本构建android侧拖拽事件，实现目标文本到android应用程序2的传输，并构建空的拖拽结束事件。
319.在上述实施例中，guest侧和host侧通过传递目标文本的文件内容来通知拖拽的目标文件。在其他一些实施例中，guest侧和host侧之间也可以不用传递目标文本的文本内容，在android应用程序1触发拖拽后，guest侧可以保存拖拽的目标文本；在拖拽释放到android应用程序2的窗口后，guest侧可以根据保存的目标文本构建android侧拖拽事件。
320.参见图11c，在步骤1107或步骤1111之后，该方法还可以包括：
321.1112、guest侧android应用程序2根据目标对象和释放位置进行处理。
322.关于该步骤的说明可以参见上述步骤612中的相关描述，不予赘述。
323.示例性的，目标对象为目标文件，基于图12中的(a)所示的用户将目标文件(即图片b)从android应用程序1(如android文件管理)的窗口1201到android应用程序2(如android社交应用)的窗口1202中信息编辑窗口的拖拽操作，参见图12中的(b)，android应用程序2的窗口中添加了目标文件，且目标文件发送给了聊天界面对应的联系人，实现了目标文件从android应用程序1到android应用程序2的复制。
324.需要说明的是，不限于图12举例所采用的应用程序，当android应用程序为其他应用程序时，仍可以采用以上实施例提供的方法，实现android应用程序间传输目标对象，此
处不再一一举例。
325.还需要说明的是，在场景(3)中，以上多个实施例中的部分或全部步骤(例如图11c所示流程中的部分步骤)，在不冲突的情况下，可以重新组合，从而构成新的实施例。本技术实施例对此不再具体说明。
326.可见，针对上述场景(3)，本技术实施例通过qemu pipe通信可以实现android模拟器host侧与guest侧之间进行通信交互，通过确定拖拽源窗口与目的窗口均为android应用程序窗口，模拟在android操作系统内部进行拖拽传输，实现windows操作系统上不同android应用程序之间拖拽传输目标对象。
327.在图11a-图12描述的方案中，基于用户将目标对象从源端android应用程序的窗口，拖拽至目的端android应用程序的窗口的简单的一步拖拽操作，即可实现windows操作系统上不同android应用程序之间的目标对象的传输，而不需要用户进行多步、复杂的操作。并且，用户通过鼠标等输入设备在窗口间的拖拽操作，更符合用户基于windows操作系统和电脑的操作使用习惯，因而用户使用体验较好，能够增加产品的竞争力。而且，该方案不需要通过共享文件夹或windows侧来中转目标文件，因而传输速度快。此外，该方案不需要依赖adb、socket通信和网络能力等因素，不会受到这些因素的限制，文件传输速度快且安全可靠。
328.需要说明的是，场景(1)-(3)描述的方案为基于用户的一步拖拽操作来复制目标对象。在其他一些实施例中，电脑可以基于用户的一步拖拽操作来剪切目标对象(例如目标文件或目标文本等)，即将目标对象从源端应用程序传输到目的端应用程序，并删除源端应用程序中的该目标文件。比如，基于用户针对目标对象从windows应用程序到android应用程序的一步拖拽操作，可以将windows应用程序中的目标对象剪切至android应用程序；基于用户针对目标对象从android应用程序到windows应用程序的一步拖拽操作，可以将android应用程序中的目标对象剪切至windows应用程序；基于用户针对目标对象从android应用程序1到android应用程序2的一步拖拽操作，可以将android应用程序1中的目标对象剪切至android应用程序2。
329.在本技术的一些实施例中，在上述场景(1)-(3)中，可传输的目标对象也可以为文件夹，且文件夹的传输方式与文件的传输方式相同。也可以理解为，目标对象类型中的文件包括文件夹。
330.在本技术的另一些实施例中，在上述场景(1)-(3)中，可传输的目标对象不能为文件夹，若拖拽的目标对象为文件夹，则host侧直接通知源窗口不允许拖拽，拖拽文件夹在android应用程序窗口释放时，host侧可以提示用户(例如通过弹窗等方式来提示用户)不允许拖拽文件夹；从android侧窗口中拖拽文件夹时，guest侧也不会将拖拽信息通知给host侧。
331.场景(4)、复制和粘贴操作实现windows应用程序到android应用程序的文件传输：
332.在该交互场景中，用户可以通过鼠标、触摸屏或键盘快捷键，基于windows应用程序窗口中的目标对象执行复制操作(例如点击鼠标右键后选择复制选项，或者按下键盘上的ctrl c快捷键等)，并在android应用程序的窗口中执行粘贴操作(例如点击粘贴选项，按下键盘上的ctrl v快捷键，或者点击鼠标右键后选择粘贴选项等)。电脑根据用户的复制和粘贴操作，将windows应用程序中的目标文件复制到android应用程序，实现windows应用程
序到android应用程序的文件传输。
333.针对该场景(4)，参见图13a，本技术实施例提供了一种文件传输方法，包括：首先，android模拟器host侧执行复制文件操作，将复制文件路径放共享剪贴板。通过windows isclipboardformatavailable()，可以区分共享剪贴板中的数据类型是文本、文件或其他。其次，当android模拟器guest侧(即android系统)应用程序中进行粘贴文件操作时，对粘贴目的路径，粘贴文件等进行文件权限、容量等权限检查。检查通过之后，guest侧通过host侧发起文件复制操作。host侧收到文件复制操作请求后，检查源文件是否存在。检查通过之后，显示复制进度条；同时开始将源文件复制到共享文件夹中(在模拟器启动时mount的目录)；复制完成之后，host侧通知guest侧复制完成。guest侧收到文件复制完成消息后，再将文件从共享文件夹复制到android目的目录中，然后将共享文件夹中的文件删除；最后通知host侧文件复制成功(若未复制成功则回复复制失败)。在host侧收到文件复制成功消息后，复制进度条显示完成。
334.在其他一些实施例中，结合图13b所示的流程图及图14-图16所示的界面示意图，对本技术提供的跨系统传输目标对象的方法进行详细说明：
335.1300、host侧检测到windows应用程序的窗口中针对目标对象的复制操作。
336.示例性的，参见图14中的(a)，目标对象为windows资源管理器的窗口1401中的文档1和文档2，用户针对目标文件按下键盘上的ctrl c快捷键，以指示复制该目标对象，此时host侧检测到针对目标对象的复制操作。
337.若目标对象为目标文件，则执行步骤1301-1311；若目标对象为目标文本，则执行步骤1312-1317。
338.1301、若目标对象为目标文件，则host侧响应于用户的复制操作，将目标文件的路径信息存放到host侧剪贴板中。
339.1302、host侧监控host侧剪贴板的变化，将host侧剪贴板中目标文件的路径信息存放到共享剪贴板中。
340.其中，host侧可以基于qemu pipe，将host侧剪贴板中目标文件的路径信息存放到共享剪贴板中。
341.1303、guest侧检测到android应用程序的窗口中的粘贴操作，该粘贴操作用于指示在该窗口中粘贴目标文件。
342.示例性的，参见图14中的(b)，用户在android文件管理的窗口1402中按下键盘上的快捷键ctrl v执行粘贴操作(或者，用户也可以点击粘贴选项1403的粘贴操作)，此时guest侧检测到该粘贴操作。
343.电脑检测到用户执行的粘贴操作后，通过以下步骤将共享剪贴板中的路径信息对应的目标文件，粘贴至目的端android文件管理窗口。
344.1304、guest侧对android应用程序对应的待粘贴目的路径，以及共享剪贴板中的路径信息对应的目标文件进行预检查，并在预检查通过后，基于qemu pipe向host侧发起目标文件复制请求。
345.例如，该预检查包括检查待粘贴目的路径是否存在、是否合法，对目标文件进行权限和容量检查等。其中，该预检查操作可以为可选操作。
346.1305、host侧接收到复制请求后，确定源目标文件是否存在。
347.1306、若host侧确定源目标文件存在，则将共享剪贴板中的路径信息对应的目标文件拷贝到9p共享文件夹，在拷贝完成后基于qemu pipe通知guest侧。
348.其中，当目标文件包括多个文件时，host侧可以每拷贝完目标文件中的一个文件后，就通知guest侧；也可以在目标文件的全部文件都拷贝完后再通知guest侧。
349.1307、guest侧接收到拷贝完成通知后，将目标文件从9p共享文件夹复制到android应用程序。
350.1308、guest侧的android应用程序根据粘贴位置进行相应处理。
351.关于该步骤的说明可以参见上述步骤612中的相关描述。示例性的，基于图14中的(a)-(b)所示的复制和粘贴操作，参见图14中的(c)，android文件管理窗口中添加了目标文件，实现了目标文件从windows资源管理器到android文件管理的复制。
352.1309、guest侧将共享文件夹中的目标文件删除，并基于qemu pipe通知host侧传输完成。
353.后续，响应于用户在其他android应用程序的窗口中的粘贴操作，可以重新执行步骤1303-1309，从而将目标文件复制到其他android应用程序的窗口中，实现多次粘贴。
354.在上述过程中，用户执行的是复制和粘贴操作，在其他一些实施例中，如果用户通过鼠标或键盘的快捷键等方式，基于windows应用程序窗口中的目标文件执行剪切操作，则在上述步骤1309之后，该方法还包括：
355.1310、host侧接收到传输完成通知后，删除windows应用程序中的目标文件，删除host剪贴板中目标文件的路径信息。
356.1311、host侧同步host剪贴板的变化，删除共享剪贴板中存放的目标文件的路径信息。
357.示例性的，目标对象为目标文件，针对图15中的(a)-(b)所示的用户基于windows资源管理器窗口1501中的目标文件，按下快捷键ctrl x的剪切操作，以及用户基于android文件管理窗口1502按下快捷键ctrl v的粘贴操作(或者用户点击粘贴选项1503的粘贴操作)，参见图15中的(c)，android文件管理窗口中添加了目标文件，windows资源管理器中删除了目标文件，实现了从windows资源管理器剪切目标文件并粘贴到android文件管理的过程。
358.在一些实施例中，host侧还可以在目标文件的复制/剪切过程中显示传输进度条。例如，该传输进度条为复制进度条，host侧在确定源文件存在后，可以显示复制进度条；在接收到来自guest侧的文件复制完成通知后，复制进度条显示完成。
359.在步骤1300之后，若目标对象为目标文本，则执行以下步骤：
360.1312、若目标对象为目标文本，则host侧响应于用户的复制操作，将目标文本存放到host剪贴板中。
361.1313、host侧监控host侧剪贴板的变化，将host侧剪贴板中目标文本存放到共享剪贴板中。
362.1314、guest侧检测到android应用程序的窗口中的粘贴操作，该粘贴操作用于指示在该窗口中粘贴目标文本。
363.1315、guest侧对android应用程序对应的待粘贴目的路径，以及共享剪贴板中目标文本进行预检查。
364.其中，该步骤1315为可选的步骤。
365.1316、guest侧在预检查通过后，将共享剪贴板中的目标文本复制到android应用程序。
366.1317、guest侧的android应用程序根据粘贴位置进行相应处理。
367.例如，android应用程序根据具体的粘贴位置，将目标文本插入到粘贴位置，或者将目标文本发送给联系人。
368.示例性的，目标对象为目标文本，针对图16中的(a)-(b)所示的用户基于windows应用程序(如windows应用程序1)窗口1601中的目标文本按下快捷键ctrl c的复制操作，以及用户基于android应用程序(如android社交应用)窗口1602按下快捷键ctrl c的粘贴操作，参见图16中的(c)，android应用程序中添加了目标文本，且目标文本发送给了对应的联系人，实现了目标文本从android文件管理到android社交应用的复制。
369.如果用户执行的是剪切和粘贴操作，则在上述步骤1317之后，该方法还包括：
370.1318、host侧删除windows应用程序中的目标文本。
371.本技术实施例通过qemu pipe通信实现android模拟器host侧与guest侧进行通信交互，通过如图4所示的共享剪贴板复制文件路径，通过virtio-9p实现host侧与guest侧的文件共享，或者通过共享剪贴板实现host侧与guest侧的文本共享，从而实现在windows应用程序与android应用程序之间复制/剪切文件或文本。
372.该方案在9p共享文件系统的基础上，实现了windows与android模拟器侧共享剪贴板的相关操作。在用户体验上实现了windows侧与android侧剪贴板的功能，与windows与android剪贴板的使用方式保持一致，符合用户的操作使用习惯。
373.在图13a-图16描述的方案中，基于用户在源端windows应用程序的窗口针对目标对象的简单的复制/剪切操作，和在目的端android应用程序的窗口的简单的粘贴操作，即可实现windows应用程序到android应用程序的目标对象的复制/剪切，而不需要用户进行多步、复杂的操作。并且，用户通过鼠标或键盘等输入设备在窗口内的复制/剪切和粘贴操作，更符合用户基于windows操作系统和电脑的操作使用习惯，因而用户使用体验较好，能够增加产品的竞争力。而且，该方案不需要依赖adb、socket通信和网络能力等因素，文件传输速度快且安全可靠。
374.需要说明的是，在场景(4)中，以上多个实施例中的部分或全部步骤(例如图13b所示流程中的部分步骤)，在不冲突的情况下，可以重新组合，从而构成新的实施例。本技术实施例对此不再具体说明。
375.场景(5)、复制和粘贴操作实现android应用程序到windows应用程序的文件传输：
376.在该交互场景中，用户可以通过鼠标、触摸屏或键盘的快捷键，基于android应用程序窗口中的目标文件执行复制操作(例如选中目标对象后点击对应的复制选项，或者在目标对象后长按鼠标左键后点击出现的复制选项，或者按下键盘上的ctrl c快捷键，或者针对目标文件点击鼠标右键后选择复制选项等)，并在windows应用程序的窗口中执行粘贴操作(例如点击鼠标右键后选择粘贴选项，或者按下键盘上的ctrl v快捷键等)。电脑根据用户的复制和粘贴操作，将android应用程序中的目标文件复制到windows应用程序，实现android应用程序到windows应用程序的文件传输。
377.以下结合图17所示的流程图及图18所示的界面示意图进行说明：
378.1700、guest侧检测到android应用程序的窗口中针对目标对象的复制操作。
379.若目标对象为目标文件，则执行步骤1701-1711；若目标对象为目标文本，则执行步骤1712-1717。
380.1701、若目标对象为目标文件，则guest侧响应于用户的复制操作，将目标文件的路径信息存放到guest侧剪贴板中。
381.1702、guest侧监控guest侧剪贴板的变化，将guest侧剪贴板中目标文件的路径信息存放到共享剪贴板中。
382.其中，guest侧可以基于qemu pipe，将guest侧剪贴板中目标文件的路径信息存放到共享剪贴板中。
383.1703、host侧检测到windows应用程序窗口中的粘贴操作，该粘贴操作用于指示在该窗口中粘贴目标文件。
384.1704、host侧对windows应用程序窗口对应的待粘贴目的路径，以及共享剪贴板中的路径信息对应的目标文件进行预检查，并在预检查通过后，基于qemu pipe向guest侧发起目标文件复制请求。
385.其中，该预检查操作可以为可选操作。
386.1705、guest侧接收到复制请求后，确定源目标文件是否存在。
387.1706、若guest侧确定源目标文件存在，则将源目标文件拷贝到9p共享文件夹，并在拷贝完成后，基于qemu pipe通知host侧。
388.其中，当目标文件包括多个文件时，guest侧可以每拷贝完目标文件中的一个文件后，就通知host侧；也可以在目标文件的全部文件都拷贝完后再通知host侧。
389.1707、host侧将目标文件从共享文件夹复制到windows应用程序。
390.1708、host侧的windows应用程序根据粘贴位置进行相应处理。
391.该步骤的相关说明可以参见步骤612中的相关描述。例如，windows应用程序根据具体的粘贴位置，将目标文件复制到粘贴位置对应的目录下，或者将目标文件发送给联系人等。
392.示例性的，针对图18中的(a)-(b)所示的用户基于android文件管理窗口1801中的目标文件按下快捷键ctrl c的复制操作(或者，用户点击复制选项1803的复制操作)，以及用户基于windows资源管理器窗口1802按下快捷键ctrl v的粘贴操作，参见图18中的(c)，windows资源管理器窗口中添加了目标文件，实现了目标文件从android文件管理到windows资源管理器的复制。
393.1709、host侧将共享文件夹中的目标文件删除，并基于qemu pipe通知guest侧文件传输完成。
394.在上述过程中，用户执行的是复制和粘贴操作，在其他一些实施例中，如果用户通过鼠标或键盘的快捷键等方式，基于android文件管理窗口中的目标文件进行剪切操作，则在上述步骤1709之后，该方法还包括：
395.1710、guest侧接收到传输完成通知后，删除android应用程序中的目标文件，删除guest侧剪贴板中目标文件的路径信息。
396.1711、guest侧同步guest侧剪贴板的变化，删除共享剪贴板中存放的目标文件的路径信息。
397.在一些实施例中，电脑在目标文件的复制/剪切过程中还可以显示传输进度条。
398.在步骤1701之后，若目标对象为目标文本，则执行以下步骤：
399.1712、若目标对象为目标文本，则guest侧响应于用户的复制操作，将目标文本存放到guest侧剪贴板中。
400.1713、guest侧监控guest侧剪贴板的变化，将guest侧剪贴板中目标文本存放到共享剪贴板中。
401.1714、host侧检测到windows应用程序窗口中的粘贴操作，该粘贴操作用于指示在该窗口中粘贴目标文本。
402.1715、host侧对windows应用程序对应的待粘贴目的路径，以及共享剪贴板中目标文本进行预检查。
403.其中，该步骤1715为可选的步骤。
404.1716、host侧在预检查通过后，将目标文本复制到windows应用程序。
405.1717、host侧的windows应用程序根据粘贴位置进行相应处理。
406.该步骤的相关说明可以参见步骤612中的相关描述。例如，windows应用程序根据具体的粘贴位置，将目标文本插入到粘贴位置，或者将目标文本发送给联系人。
407.如果用户执行的是剪切和粘贴操作，则在上述步骤1717之后，该方法还包括：
408.1718、guest侧删除android应用程序中的目标文本。
409.本技术实施例通过qemu pipe通信实现android模拟器host侧与guest侧进行通信交互，通过如图4所示的共享剪贴板复制文件路径，通过virtio-9p实现host侧与guest侧的文件共享，或者通过共享剪贴板实现host侧与guest侧的文本共享，在android应用程序与windows应用程序之间复制/剪切文本或文件。
410.该方案在9p共享文件系统的基础上，实现了windows与android模拟器侧共享剪贴板的相关操作。在用户体验上实现了windows侧与android侧剪贴板的功能，与windows与android剪贴板的使用方式保持一致，符合用户的操作使用习惯。
411.在图17-图18描述的方案中，基于用户在源端android应用程序的窗口针对目标文件的简单的复制/剪切操作，和在目的端windows应用程序的窗口的简单的粘贴操作，即可实现android应用程序到windows应用程序的文件复制/剪切，而不需要用户进行多步、复杂的操作。并且，用户通过鼠标或键盘等输入设备在窗口内的复制/剪切和粘贴操作，更符合用户基于windows操作系统和电脑的操作使用习惯，因而用户使用体验较好，能够增加产品的竞争力。而且，该方案不需要依赖adb、socket通信和网络能力等因素，文件传输速度快且安全可可靠。
412.需要说明的是，在场景(5)中，以上多个实施例中的部分或全部步骤(例如图17所示流程中的部分步骤)，在不冲突的情况下，可以重新组合，从而构成新的实施例。本技术实施例对此不再具体说明。
413.场景(6)、复制和粘贴操作实现android应用程序到另一android应用程序的文件传输：
414.在该交互场景中，用户可以通过鼠标、触摸屏或键盘的快捷键，基于android应用程序1窗口中的目标文件执行复制操作(例如选中目标文件后点击对应的复制选项，或者在目标对象后长按鼠标左键后点击出现的复制选项，或者按下键盘上的ctrl c快捷键，或者
针对目标文件点击鼠标右键后选择复制选项等)，并在android应用程序2的窗口中执行粘贴操作(例如点击粘贴选项，按下键盘上的ctrl v快捷键，或者点击鼠标右键后选择粘贴选项等)。电脑根据用户的复制和粘贴操作，将android应用程序1中的目标文件复制到android应用程序1，实现android应用程序间的文件传输。
415.以下结合图19所示的流程图及图20所示的界面示意图进行说明：
416.1900、guest侧检测到android应用程序1窗口中针对目标对象的复制操作。
417.若目标对象为目标文件，则执行步骤1901-1908；若目标对象为目标文件，则执行步骤1909-1915。
418.1901、若目标对象为目标文件，则guest侧响应于用户的复制操作，将目标文件的路径信息存放到guest侧剪贴板中。
419.1902、guest侧监控guest侧剪贴板的变化，将guest侧剪贴板中目标文件的路径信息存放到共享剪贴板中。
420.其中，guest侧可以基于qemu pipe，将guest侧剪贴板中目标文件的路径信息存放到共享剪贴板中。
421.1903、guest侧检测到android应用程序2窗口中的粘贴操作，该粘贴操作用于指示在该窗口中粘贴目标文件。
422.1904、guest侧对当前android应用程序2窗口对应的待粘贴目的路径，以及共享剪贴板中的路径信息对应的目标文件进行预检查。
423.其中，该预检查可以为可选操作。
424.1905、guest侧在预检查通过后，确定源目标文件是否存在。
425.1906、若guest侧确定源目标文件存在，则将共享剪切板中的路径信息对应的目标文件复制到android应用程序2。
426.1907、guest侧的android应用程序2根据粘贴位置进行相应处理。
427.示例性的，针对图20中的(a)-(b)所示的用户基于android文件管理窗口2001中的目标文件按下快捷键ctrl c的复制操作(或者用户点击复制选项2003的复制操作)，以及用户基于android社交应用窗口2002按下快捷键ctrl v的粘贴操作，参见图20中的(c)，android社交应用窗口中添加了目标文件，且目标文件发送给了对应的联系人，实现了目标文件从android文件管理到android社交应用的复制。
428.在上述过程中，用户执行的是复制和粘贴操作，在其他一些实施例中，如果用户通过鼠标或键盘的快捷键等方式，基于android文件管理窗口中的目标文件进行剪切操作，则在上述步骤1907之后，该方法还包括：
429.1908、guest侧删除android应用程序1中的目标文件。
430.在一些实施例中，电脑在目标文件的复制/剪切过程中还可以显示传输进度条。
431.也就是说，本技术实施例通过qemu pipe通信实现android模拟器host侧与guest侧进行通信交互，通过共享剪贴板复制文件路径，在android应用程序之间复制/剪切目标文件。
432.在步骤1901之后，若目标对象为目标文本，则执行以下步骤：
433.1909、若目标对象为目标文本，则guest侧响应于用户的复制操作，将目标文本存放到guest侧剪贴板中。
434.1910、guest侧监控guest侧剪贴板的变化，将guest侧剪贴板中目标文本存放到共享剪贴板中。
435.1911、guest侧检测到android应用程序2窗口中的粘贴操作，该粘贴操作用于指示在该窗口中粘贴目标文本。
436.1912、guest侧对android应用程序对应的待粘贴目的路径，以及共享剪贴板中目标文本进行预检查。
437.其中，该步骤1912为可选的步骤。
438.1913、guest侧在预检查通过后，将目标文本复制到android应用程序2。
439.1914、guest侧的android应用程序2根据粘贴位置进行相应处理。
440.该步骤的相关说明可以参见步骤612中的相关描述。例如，android应用程序2根据具体的粘贴位置，将目标文本插入到粘贴位置，或者将目标文本发送给联系人。
441.如果用户执行的是剪切和粘贴操作，则在上述步骤1914之后，该方法还包括：
442.1915、guest侧删除android应用程序1中的目标文本。
443.该方案在用户体验上实现了android侧剪贴板的功能，与android剪贴板的使用方式保持一致，符合用户的操作使用习惯。
444.在图19-图20描述的方案中，基于用户在源端android应用程序1的窗口针对目标对象的简单的复制/剪切操作，和在目的端android应用程序2的窗口的简单的粘贴操作，即可实现android应用程序间的目标对象的复制/剪切，而不需要用户进行多步、复杂的操作。并且，用户通过鼠标或键盘等输入设备在窗口内的复制/剪切和粘贴操作，更符合用户基于windows操作系统和电脑的操作使用习惯，因而用户使用体验较好，能够增加产品的竞争力。而且，该方案不需要依赖adb、socket通信和网络能力等因素，文件传输速度快且安全可靠。
445.需要说明的是，在场景(6)中，以上多个实施例中的部分或全部步骤(例如图19所示流程中的部分步骤)，在不冲突的情况下，可以重新组合，从而构成新的实施例。本技术实施例对此不再具体说明。
446.在本技术的一些实施例中，在上述场景(4)-(6)中，可传输的目标对象也可以为文件夹，且文件夹的传输方式与文件的传输方式相同。也可以理解为，目标对象类型中的文件包括文件夹。
447.在本技术的另一些实施例中，在上述场景(4)-(6)中，可传输的目标对象不能为文件夹，若目标对象为文件夹，则host侧直接通知源窗口不允许复制/剪切，用户在android应用程序窗口执行粘贴操作时，host侧可以提示用户(例如通过弹窗等方式来提示用户)不允许复制/剪切；在android侧窗口中执行复制/剪切文件夹的操作时，guest侧也不会将相关信息通知给host侧。
448.在其他一些实施例中，在传输目标对象的过程中，第一操作系统与第二操作系统之间可以通过socket或其他通信技术进行通信交互。
449.可以理解的是，为了实现上述功能，电子设备包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本技术能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例
对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
450.本实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
451.在采用对应各个功能划分各个功能模块的情况下，上述实施例中涉及的电子设备的一种可能的组成示意图，该电子设备可以包括：显示单元、传输单元和处理单元等。需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
452.本技术实施例还提供一种电子设备，包括一个或多个处理器以及一个或多个存储器。该一个或多个存储器与一个或多个处理器耦合，一个或多个存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，使得电子设备执行上述相关方法步骤实现上述实施例中的跨系统传输目标对象的方法。
453.本技术的实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的跨系统传输目标对象的方法。
454.本技术的实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中电子设备执行的跨系统传输目标对象的方法。
455.另外，本技术的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使装置执行上述各方法实施例中电子设备执行的跨系统传输目标对象的方法。
456.其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或装置均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
457.通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
458.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
459.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到
多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
460.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
461.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
462.以上内容，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。