Distributed continuation across devices

What it is

HarmonyOS and related Mainland systems rebind a task from “this device” to “this account session,” so work in progress can continue on a nearby device: a note unfinished on the phone is finished on the tablet, navigation started in the car returns to the phone after parking, a call on the television can be hung up from the watch. This is not “open the same account on two devices and sync later.” It is live migration of one task—scroll position, draft input, and playback travel with the session. Discovering nearby devices, confirming the handoff, and restoring on the destination are system interactions, not a device list each app invents.

This is how a task continues across devices, not how one codebase picks layouts by capability. The latter is a compile- and layout-time choice; continuation happens inside a running session.

Why it happens

Continuation works because the task is a serializable session: an identity for “this piece of work,” a minimal state blob, and a declaration of capabilities the destination must have (screen, microphone, location, car hardware keys). The system matches nearby devices on those capabilities and shows a system picker; the app does not scan the LAN. The source may keep a stub that can be resumed, or go idle; the destination restores the same session, not a second instance. What the user recognizes is “the thing I was doing,” not “another window of the same kind.”

When capabilities do not match, continuation must fail clearly: a watch cannot take over a long document in edit, and must not pretend success and drop the text. Media tasks also decide where sound and picture live—a call may move only its controls to the watch while audio stays in the car. Failure, cancel, and switch-back all go through the same system sheet, or users will think the task was duplicated and edit both ends.

Where it stops holding

If devices do not share an account, are not nearby, or are in airplane mode, there is nothing to discover; the affordance should vanish rather than throw a generic error. Steps that involve payment, passwords, or one-time codes must not travel silently—the destination reconfirms, or “a nearby device” becomes an attack surface. Browser pages and mini-programs hosted by a super-app may not live in the system task model at all; continuation then degrades to “open the same URL,” with position and form data not guaranteed. On shared surfaces (a living-room TV, a communal car head unit), who can see the screen matters; private drafts should not be thrown across. If the app never declared a continuable capability, the system will not invent a migration for it.

Applying it

• Make the primary task a serializable session: persist position, drafts, and playback, and declare required destination capabilities, rather than syncing only a cloud document.
• Use the system’s device picker and confirmation sheet. Do not ship an in-app LAN device list.
• Fail visibly when capabilities are missing, and keep the source session. Reconfirm identity and payment on the destination.
• Verify by continuing a task from a phone to a tablet on the same account: the destination must pick up the same scroll offset and unsubmitted input, and the source stub-or-idle behavior must match intent. Then try a device that obviously cannot take the task (a watch receiving a long form) and confirm failure is visible and the source content remains. Cancel one continuation and confirm the work did not fork into two edits.

Related

• Same group: R4.04.2 Constraints of mini-programs inside super-apps · R4.04.3 Points of divergence from international platform conventions · R4.04.4 Multi-end deployment requires layout by capability, not screen name · R4.04.5 Service cards surface functions at the desktop layer · R4.04.6 System-owned identity and payment change flow boundaries
• Adjacent: K1.08 App switching and background eviction · K1.11 Deep links and app-to-app jumps
• Search terms: distributed continuation · task migration · HarmonyOS · handoff