Cross-screen flow transfer method and electronic device

Abstract

The application provides a cross-screen flow transfer method and electronic equipment. The cross-screen flow transfer method is cooperatively executed by a Linux main system and an Android subsystem, and comprises the following steps: S1: the Linux system identifies a cross-screen flow transfer command, and determines a source screen and a target screen; S2: the Linux system performs screen capturing on the source screen and the target screen, and displays the captured screen as a top cover layer; S3: the Linux system sends an application migration instruction to the Android system; the Android system checks a migration condition, and after the checking succeeds, migrates an application layer from the source screen to the target screen, and covers a transition layer on the application layer; S4: the Linux main system executes an out scene animation on the source screen static image on the source screen; S5: the Linux main system adjusts the target screen layer sequence, promotes the application layer to above the target screen static image, and executes an in scene animation, wherein the in scene animation is performed under the cover of the transition layer; and S6: after the in scene animation is completed, the target screen static image and the transition layer are removed. The cross-screen flow transfer realizes an absolutely smooth and coherent experience in vision.

Description

Technical Field

[0001] This invention relates to the field of automotive automation control technology, and more specifically, to a cross-screen transfer method and electronic device. Background Technology

[0002] With the development of automotive intelligent technology, in order to meet the diverse and scenario-based needs of drivers and passengers, the number of displays in modern intelligent vehicles is constantly increasing. However, these screens do not exist in isolation; they collectively construct a coherent and collaborative multi-screen interactive environment. Drivers and passengers, or passengers in different seats, can achieve seamless content sharing, task handover, and collaborative control through the screens.

[0003] In a single operating system like Windows or Android, application windows can be dragged and dropped onto an extended display via wired or wireless connections. This method relies on the operating system's native multi-screen management module and is unsuitable for environments where two independent systems, Linux and Android, coexist. Another approach involves running a virtual machine on the host system and displaying applications from within the virtual machine as independent windows on the host desktop. This method typically requires complex graphics pass-through techniques, and the application window's integration with the host system is poor, making it difficult to achieve a unified, smooth interactive experience and screenshot-like visual effects. If the application is launched directly on the target screen and attempts to restore its state from the source screen, this method fails to maintain the application's immediate state, resulting in noticeable interruptions and delays during the migration process, leading to a poor user experience.

[0004] Because Linux and Android are independent systems with their own graphics stacks (Linux uses compositors like Weston, while Android uses SurfaceFlinger), Android applications cannot be directly migrated to a different physical screen managed by the Linux system, unlike applications within a single system. Furthermore, during application migration, directly switching display content results in abruptly blank source screens, black screens when applications launch on the target screen, or abruptly stretched and abruptly changed visuals, creating a jarring and disjointed experience.

[0005] Therefore, in a smart cockpit based on the collaborative operation of Linux and Android dual systems, when an application needs to migrate between screens with different display architectures and resolutions, the inherent processing delays in its underlying display context switching, interface re-layout, and state synchronization will be directly exposed as visible screen flickering, image jumps, or brief abnormal displays, resulting in a break in the user experience. Existing technical solutions, lacking effective visual buffering and transition mechanisms, cannot cover up the visual discontinuities that inevitably occur during the processing. Summary of the Invention

[0006] The purpose of this invention is to provide a cross-screen transition method and electronic device. By establishing a multi-layer visual masking and collaborative transition mechanism, the inherent processing delay and display gaps of applications during cross-system migration can be effectively masked, thereby achieving an absolutely smooth and coherent cross-screen transition experience.

[0007] To achieve the above objectives, this invention provides a cross-screen transition method, which is executed collaboratively by a Linux host system and an Android subsystem, including the following steps: S1: The Linux host system recognizes the cross-screen transition command and determines the source screen and the target screen; S2: In response to the cross-screen transition command, the Linux host system takes screenshots of the current display content of the source screen and the target screen, generating static images of the source screen and the target screen, which are then displayed as top-level overlay layers, respectively; S3: The Linux host system sends an application migration command to the Android subsystem; the Android subsystem verifies the migration conditions, and upon successful verification, migrates the application layer from the display area of ​​the source screen to the display area of ​​the target screen, and overlays a transition layer on the application layer; S4: The Linux host system executes an entrance animation on the source screen's static image; S5: The Linux host system adjusts the layer order of the target screen, elevating the application layer above the target screen's static image, and executes an entrance animation, which is performed under the cover of the transition layer; S6: After the entrance animation is completed, the Linux host system removes the target screen's static image, and the Android subsystem removes the transition layer after the application interface stabilizes.

[0008] The technical effects achieved by adopting this solution are as follows: When a user triggers a cross-screen transition, the Linux host system immediately takes screenshots of both the source and target screens and displays these static screenshots as the highest-level overlay layer on the physical screen. This instantly freezes the user's current visual perception, preventing the user from seeing the application immediately disappear or the target screen become blank. Next, Linux sends an application migration command to the Android subsystem. During the process of application migration, layout, and rendering of the new interface within the Android system, to conceal any potential screen jumps or flickering, Android's window management service displays a transition layer on the target screen. This transition layer acts as a temporary visual mask, ensuring that the user does not see any unstable states of the application adapting to the new screen. The Linux host system initiates the visual transition coordination. On the source screen, the previously displayed static screenshot layer executes an entrance animation. On the target screen, the Linux host system adjusts the layer order, elevating the actual application layer, which is being rendered below the transition layer, to a higher level than the static screenshot layer. An entrance animation is then executed for this application layer, performed entirely under the cover of the transition layer. This ensures the user sees a smooth, flawless application entry process without any intermediate rendering layers. Once the application layer's entrance animation on the target screen is complete, the Linux host system removes the static screenshot overlay layer from the target screen. The transition layer is independently controlled by the Android system and is removed once the application layer has fully adapted to the new screen and is stably displayed. This application, by establishing a multi-layered visual masking and collaborative transition mechanism, effectively conceals the inherent processing delays and display gaps during application migration across systems, thereby achieving a visually absolutely smooth and coherent cross-screen experience. It solves the technical problem of how to achieve seamless, smooth, and visually excellent cross-screen transitions for Android foreground applications between different physical screens in a dual-system architecture where Linux is the host system and Android is the subsystem.

[0009] Preferably, the cross-screen transition command is triggered by user interaction, and the cross-screen transition command includes at least one of the following: a) touch screen control commands; b) voice commands; c) human motion commands.

[0010] The technical effects achieved by adopting this solution are as follows: By supporting multiple interaction methods such as touch, voice, and gesture to trigger cross-screen flow commands, users can trigger cross-screen flow in a simple and diverse way, improving the intuitiveness and ease of use of the user experience.

[0011] Preferably, in step S2, while displaying the static image of the source screen, the Linux host system switches the actual screen of the source screen to the Linux host system interface.

[0012] The technical effect achieved by adopting this technical solution is as follows: While the Linux host system displays the static image of the source screen, the Linux host system switches the actual screen of the source screen to the Linux host system interface. In other words, when the Linux host system executes the appearance animation on the static image of the source screen, the Linux host system interface is already ready, further ensuring the seamless and absolutely smooth cross-screen transition.

[0013] Preferably, in step S3, the Linux host system sends application migration instructions to the Android subsystem through a pre-established dual-system communication module.

[0014] The technical effects achieved by adopting this solution are as follows: The pre-established dual-system communication module enables the Linux host system to send application migration instructions to the Android subsystem. The pre-established dual-system communication module ensures reliable and efficient instruction transmission and state synchronization between the Linux host system and the Android subsystem. This dedicated communication channel avoids the complexity and potential delays of inter-system communication and is the foundation for achieving seamless cross-screen transition. It ensures that instructions can reach the Android system in a timely and accurate manner and be processed, thereby coordinating the smooth progress of the entire cross-screen transition process.

[0015] Preferably, in step S3, after receiving the application migration instruction, the Android subsystem's Activity Task Manager service verifies the migration conditions.

[0016] The technical effects achieved by adopting this solution are as follows: By performing migration condition verification through the Active Task Manager Service (ATMS) of the Android subsystem, it is possible to determine whether there are meaningless background applications performing cross-screen transitions, ensuring that only foreground applications that the user is truly concerned about are migrated, thereby preventing invalid operations and potential visual confusion, and improving the stability of the system and the accuracy of user operations.

[0017] Preferably, in step S3, the Android subsystem verifies the migration conditions and returns the verification result to the Linux host system. If the verification fails, the cross-screen transfer command is canceled.

[0018] The technical effects achieved by adopting this solution are as follows: Based on the verification result returned by the Android subsystem, the Linux main system continues execution if the verification is successful, and cancels if it fails. This solution provides an error handling strategy for cross-screen application transitions. When the verification fails, the system can promptly stop the cross-screen transition command, avoiding unnecessary animations or state changes. This prevents visual flickering, blank screens, or application crashes caused by invalid migration attempts, ensuring system stability and consistent user experience.

[0019] Preferably, in step S5, the Linux host system adjusts the target screen layer order through the Linux graphics compositor.

[0020] The technical effects achieved by adopting this solution are as follows: Linux's graphics compositor can efficiently manage and render multiple layers. By precisely adjusting the Z-order, it ensures that Android application layers are displayed in the correct order at the correct time and executes smooth entrance animations, thereby achieving seamless visual transitions and avoiding screen tearing or flickering.

[0021] Preferably, the transition layer is customizable.

[0022] The technical effects achieved by adopting this solution are as follows: Through a customizable transition layer, it not only covers the visual discontinuity during application re-layout and rendering, but also clearly conveys to the user that the system is performing a cross-screen transition operation, reducing the user's waiting anxiety and uncertainty, and making the entire cross-screen transition process more user-friendly and easier to understand.

[0023] Preferably, in step S5, the transition layer is set to a minimum display duration, which at least covers the execution duration of the entrance animation.

[0024] The technical effect achieved by adopting this solution is as follows: By setting the minimum display duration of the transition layer, the transition layer remains displayed for its minimum duration. Even if the application itself is fast and stable, it can provide a unified and consistent visual experience, completely masking any screen jumps that may occur after the animation ends, thus achieving an absolutely smooth and consistent user experience.

[0025] The present invention also provides an electronic device, which includes at least two physical displays, a processor, and a memory; wherein the memory is used to store computer program code, the computer program code including computer instructions; when the computer instructions are executed by one or more processors, the electronic device performs the cross-screen streaming method as described in any of the above technical solutions.

[0026] The technical effects achieved by adopting this technical solution are as follows: The electronic device provided by this invention realizes the cross-screen flow method of any of the above technical solutions, ensuring the end-to-end experience from user interaction and inter-system collaboration to multi-screen graphics output, and ultimately providing users with a stable, smooth and seamless cross-screen interactive experience. Attached Figure Description

[0027] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1A flowchart illustrating the steps of the cross-screen streaming method provided in this application embodiment. Detailed Implementation

[0028] To make the above-mentioned objectives, features, and advantages of the present invention more apparent and understandable, the technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] This invention provides a cross-screen transition method, which is executed collaboratively by a Linux host system and an Android subsystem, including the following steps: S1: The Linux host system recognizes the cross-screen transition command and determines the source screen and the target screen; S2: In response to the cross-screen transition command, the Linux host system takes screenshots of the current display content of the source screen and the target screen, generating static images of the source screen and the target screen, which are displayed as top-level overlay layers respectively; S3: The Linux host system sends an application migration command to the Android subsystem; the Android subsystem verifies the migration conditions, and if the verification is successful, migrates the application layer from the display area of ​​the source screen to the display area of ​​the target screen, and overlays a transition layer on the application layer; S4: The Linux host system executes an entrance animation on the source screen's static image; S5: The Linux host system adjusts the layer order of the target screen, elevating the application layer above the target screen's static image, and executes an entrance animation, which is performed under the cover of the transition layer; S6: After the entrance animation is completed, the Linux host system removes the target screen's static image, and the Android subsystem removes the transition layer after the application interface stabilizes. See details. Figure 1 As shown.

[0030] When a user triggers a cross-screen transition, the Linux host system immediately takes screenshots of both the source and target screens and displays these static screenshots as the highest-level overlay layer on the physical screen. This instantly freezes the user's current visual perception, preventing the user from seeing the application disappear immediately or the target screen become blank. Next, Linux sends an application migration command to the Android subsystem. During the process of application migration, layout, and rendering of the new interface within the Android system, to mask potential screen jumps or flickering, Android's window management service displays a transition layer on the target screen. This transition layer acts as a temporary visual mask, ensuring the user doesn't see any instability in the application's adaptation to the new screen. The Linux host system then coordinates the visual transition. On the source screen, the previously displayed static screenshot layer performs an entrance animation. On the target screen, the Linux host system adjusts the layer order, elevating the actual application layer being rendered below the transition layer to a higher level than the static screenshot layer, and performs an entrance animation for that application layer. This entrance animation is performed entirely under the mask of the transition layer, ensuring the user sees a smooth, flawless application entry process without any intermediate rendering layers. Once the application layer's entrance animation on the target screen is complete, the Linux host system removes the static screenshot overlay layer from the target screen. The transition layer, however, is independently controlled by the Android system and is removed once the application layer has fully adapted to the new screen and is displaying stably. This application effectively masks the inherent processing latency and display gaps during cross-system migration of applications by establishing a multi-layered visual masking and collaborative transition mechanism. This achieves a visually absolutely smooth and coherent cross-screen experience, solving the technical problem of how to achieve seamless, smooth, and visually appealing cross-screen transitions for Android foreground applications across different physical screens in a dual-system architecture where Linux is the host system and Android is the subsystem.

[0031] In some embodiments of this application, cross-screen transition commands are triggered by user interaction, and these commands include at least one of the following: a) touch screen control instructions; b) voice instructions; c) human motion instructions. By supporting multiple interaction methods such as touch, voice, and gestures to trigger cross-screen transition commands, users can trigger cross-screen transitions in a simple and diverse way, improving the intuitiveness and ease of use of the user experience.

[0032] Touchscreen control commands are those that require touch to be recognized. Users can issue control commands by operating the window containing the data to be projected, such as swiping in a direction, double-tapping, or long-pressing. Voice commands are those that perform semantic recognition and analysis on voice commands within the screen projection system's context. Human gesture commands are those that do not require touch to be recognized through visual perception. They are generated by sensing human movements and recognizing their semantic information, then matching this information with specified actions in a pre-defined action library, such as three-finger swipes, turning the head to the right, nodding once, or nodding three times. In particular, using a unified gesture recognition method aligns with users' intuitive understanding of cross-screen operations, simplifies the process, and enhances the product's usability.

[0033] In some embodiments of this application, in step S2, while displaying the static image of the source screen, the Linux host system simultaneously switches the actual screen of the source screen to the Linux host system interface. By switching the actual screen of the source screen to the Linux host system interface while simultaneously displaying the static image, the Linux host system interface is already ready when the source screen's static image is executed with its own animation, further ensuring seamless and absolutely smooth cross-screen transitions.

[0034] In some embodiments of this application, in step S3, the Linux host system sends application migration instructions to the Android subsystem through a pre-established dual-system communication module. This pre-established dual-system communication module ensures reliable and efficient instruction transmission and state synchronization between the Linux host system and the Android subsystem. This dedicated communication channel avoids the complexity and potential delays of inter-system communication, forming the basis for seamless cross-screen transitions. It guarantees that instructions reach the Android system promptly and accurately for processing, thus coordinating the smooth progress of the entire cross-screen transition process.

[0035] In some embodiments of this application, in step S3, after receiving the application migration instruction, the Android subsystem verifies the migration conditions using the Android Subsystem's Active Task Manager (ATMS) service. By performing migration condition verification by the Android Subsystem's Active Task Manager (ATMS) service, it is possible to determine whether there are meaningless background applications performing cross-screen migration, ensuring that only foreground applications that the user is truly interested in are migrated. This prevents invalid operations and potential visual confusion, improving system stability and the accuracy of user operations.

[0036] In some embodiments of this application, in step S3, the Android subsystem verifies the migration conditions and returns the verification result to the Linux host system. If the verification fails, the cross-screen transition command is canceled. The Linux host system, based on the verification result returned by the Android subsystem, continues execution if the verification is successful, and cancels if it fails. This technical solution provides an error handling strategy for application cross-screen transitions. When verification fails, the system can promptly abort the cross-screen transition command, avoiding unnecessary animations or state changes. This prevents visual flickering, blank screens, or application crashes caused by invalid migration attempts, ensuring system stability and consistent user experience.

[0037] In some embodiments of this application, in step S5, the Linux host system adjusts the layer order of the target screen using the Linux graphics compositor. The Linux graphics compositor can efficiently manage and render multiple layers, ensuring that Android application layers are displayed in the correct order at the correct time by precisely adjusting the Z-order, and performing smooth entrance animations, thereby achieving seamless visual transitions and avoiding screen tearing or flickering.

[0038] In some embodiments of this application, the transition layer is customizable content. This customizable transition layer not only masks the visual discontinuities during application layout and rendering but also clearly conveys to the user that the system is performing a cross-screen transition, reducing user anxiety and uncertainty, and making the entire cross-screen transition process more user-friendly and easier to understand. Specifically, the Linux animation system and Android's transition layer management system are relatively independent, collaborating through clearly defined interaction interfaces and timing logic, reducing dependencies between system modules and improving implementation flexibility and reliability.

[0039] In some embodiments of this application, in step S5, the transition layer is set to a minimum display duration, which at least covers the execution duration of the entrance animation. By setting a minimum display duration for the transition layer, the transition layer remains displayed for its minimum duration, providing a unified and consistent visual experience even if the application itself has quickly stabilized. This completely masks any screen jumps that may occur after the animation ends, thus achieving an absolutely smooth and consistent user experience.

[0040] Embodiments of the present invention also provide an electronic device, which includes at least two physical displays, a processor, and a memory; wherein the memory is used to store computer program code, the computer program code including computer instructions; when the computer instructions are executed by one or more processors, the electronic device causes the electronic device to perform the cross-screen flow method as described in any of the above technical solutions. The electronic device of the embodiments of the present invention implements the cross-screen flow method of any of the above technical solutions, ensuring a seamless experience across the entire chain from user interaction and inter-system collaboration to multi-screen graphics output, ultimately providing users with a stable, smooth, and seamless cross-screen interactive experience.

[0041] Example 1 Imagine a user on an electronic device running both Linux and Android, with a source screen and a target screen. The user is currently using an Android application, such as a map navigation app, on the source screen for navigation. Now, the user wants to seamlessly transition this map navigation app from the source screen to the target screen so that it can be viewed by the front passenger or rear passenger.

[0042] S1: The Linux host system identifies cross-screen navigation commands and determines the source and target screens, specifically including the following steps: S11: The user performs a preset cross-screen transition gesture on the source screen, for example, swiping from the left to the right of the source screen with three fingers; S12: The Linux host system continuously monitors the input device, recognizes the three-finger swipe gesture, and determines that the flow direction is from the left screen to the right screen, where the left screen is the source screen and the right screen is the target screen.

[0043] S2: In response to the cross-screen streaming command, the Linux host system takes screenshots of the current display content of the source and target screens, generates static images of the source and target screens, and displays them as top-level overlay layers respectively. The specific steps include: S21: The Linux host system responds to the cross-screen transition command, immediately taking a screenshot of the Android layer content of the current map navigation application on the source screen, and also taking a screenshot of the Android layer on the target screen (which may be displaying the previous application at this time). These two screenshots are generated and displayed as two independent, top-level overlay layers on the top layer of the source and target screens, respectively. At this point, the user sees the static image of the map navigation application on the source screen, and its previous static image on the target screen; S22: Simultaneously with step S21, the Linux host system switches the actual screen of the source screen to the Linux host system interface. However, due to the overlay of the screenshot layer of the static image of the source screen, the user cannot see the Linux host system interface for the time being.

[0044] S3: The Linux host system sends an application migration command to the Android subsystem; the Android subsystem verifies the migration conditions, and if the verification is successful, migrates the application layer from the display area of ​​the source screen to the display area of ​​the target screen, and overlays a transition layer on the application layer; specifically, this includes the following steps: S31: Simultaneously with taking a screenshot in step S21, the Linux host system sends an application migration command to the Android subsystem through a pre-established dual-system communication module. This command contains the identifier of the target screen.

[0045] S32: After receiving the instruction, the Android subsystem's ATMS will perform a precondition check to confirm whether the map navigation application is running in the foreground; the check result will be synchronously returned to the Linux host system through the communication module. S33: If the verification passes, ATMS will move the task corresponding to the map navigation application from the display area of ​​the source screen to the display area of ​​the target screen. If the verification fails, the cross-screen flow command will be canceled.

[0046] S4: The Linux host system executes a startup animation on the source screen's static image; this includes the following steps: When the Linux host system receives the successful verification result returned by the Android subsystem, it immediately executes an entrance animation on the source screen for the map navigation application screenshot layer generated in step S21, such as the screenshot layer sliding out of the screen. During this animation, the user will see the static image of the map navigation application smoothly slide out of the source screen; at the same time, since the Linux host system has switched the actual image of the source screen to the Linux host system interface, the user will gradually see the Linux host system interface appear as the screenshot layer slides out.

[0047] S5: The Linux host system adjusts the layer order of the target screen, elevating the application layer above the static image of the target screen, and executes an entrance animation, which is performed under the cover of a transition layer; specifically, it includes the following steps: S51: While step S4 is being executed, that is, after the Android subsystem starts to perform application migration, its window management service will overlay a transition layer splash screen on the map navigation application being migrated on the target screen. The splash screen displays "Application migration in progress". S52: The Linux host system begins executing the entrance animation of the target screen, and by adjusting the layer Z order, elevates the Android map navigation application layer to a higher level than the screenshot overlay layer of the target screen; S53: Perform an entrance animation on the Android map navigation application layer, sliding in from the outside of the screen. This entrance animation is performed under the cover of the SplashScreen, with the screenshot layer below it serving as a background, ensuring the visual integrity and smooth transition of the animation process.

[0048] S6: After the entrance animation is complete, the Linux main system removes the static image from the target screen, and the Android subsystem removes the transition layer after the application interface stabilizes; specifically, this includes the following steps: S61: Once the Android map navigation application layer on the target screen has finished executing its entrance animation, the Linux host system immediately removes the screenshot overlay layer from the target screen. S62: Simultaneously with step S61, the Android subsystem will remove the SplashScreen interface after detecting that the map navigation application has completed screen adaptation and stable display. A minimum display duration is set for SplashScreen to ensure that even if the application's adaptation process is completed quickly, SplashScreen will continue to display until the Linux entrance animation ends, thus providing users with a consistent visual cue and fully covering any potential minor screen adjustments that may occur after the animation ends.

[0049] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-screen streaming method, characterized in that, The method is executed collaboratively by the Linux host system and the Android subsystem, and includes the following steps: S1: The Linux host system identifies cross-screen transition commands and determines the source screen and the target screen; S2: In response to the cross-screen streaming command, the Linux host system takes screenshots of the current display content of the source screen and the target screen, generates static images of the source screen and the target screen, and displays them as top-level overlay layers respectively; S3: The Linux host system sends an application migration command to the Android subsystem; the Android subsystem verifies the migration conditions, and if the verification is successful, migrates the application layer from the display area of ​​the source screen to the display area of ​​the target screen, and overlays a transition layer on the application layer; S4: The Linux host system executes an entrance animation on the static image of the source screen on the source screen; S5: The Linux host system adjusts the layer order of the target screen, elevates the application layer above the static image of the target screen, and executes an entrance animation, which is performed under the cover of the transition layer; S6: After the entrance animation is completed, the Linux main system removes the static image of the target screen, and the Android subsystem removes the transition layer after the application layer stabilizes.

2. The cross-screen streaming method according to claim 1, characterized in that, The cross-screen transition command is triggered by user interaction, and the cross-screen transition command includes at least one of the following: a) Touchscreen control commands; b) Voice commands; c) Human body movement instructions.

3. The cross-screen streaming method according to claim 1, characterized in that, In step S2, while displaying the static image of the source screen, the Linux host system switches the actual screen of the source screen to the Linux host system interface.

4. The cross-screen streaming method according to claim 1, characterized in that, In step S3, the Linux host system sends an application migration command to the Android subsystem through a pre-established dual-system communication module.

5. The cross-screen streaming method according to claim 1, characterized in that, In step S3, after receiving the application migration instruction, the Android subsystem verifies the migration conditions through its Activity Task Manager service.

6. The cross-screen streaming method according to claim 1, characterized in that, In step S3, the Android subsystem verifies the migration conditions and returns the verification result to the Linux main system. If the verification fails, the cross-screen transfer command is canceled.

7. The cross-screen streaming method according to claim 1, characterized in that, In step S5, the Linux host system adjusts the order of the target screen layers using the Linux graphics compositor.

8. The cross-screen streaming method according to claim 1, characterized in that, The transition layer is customizable.

9. The cross-screen streaming method according to claim 1, characterized in that, In step S5, the transition layer is set to a minimum display duration, which at least covers the execution duration of the entrance animation.

10. An electronic device, characterized in that, The electronic device includes at least two physical displays, a processor, and a memory; wherein the memory is used to store computer program code, the computer program code including computer instructions; when the computer instructions are executed by the one or more processors, the electronic device performs the cross-screen streaming method as described in any one of claims 1-9.

Images