Notifications for Large Model Downloads

Direct answer

A model-download notification should mirror the authoritative transfer state; it should not become the state store. Define one task identity and a user-readable phase such as queued, waiting for a network constraint, transferring, paused, cancelled, verifying, installing, failed, or ready. Show byte progress only when the denominator is trustworthy, and keep verification and model loading separate from bytes transferred. Provide clear actions that route to the transfer owner, such as open details or cancel, and ensure tapping a notification returns to the same artifact and current state. If notification permission is denied or a channel is disabled, the transfer state must remain available inside the app and must not be interpreted as cancelled or complete. Android notification behavior depends on permission and channel settings. On Android 13 and later, notifications for many apps require runtime permission; users can deny it, and app design must not assume a visible notification. Notification channels are user-controlled after creation, so an app cannot force a disabled channel back on. A foreground service may be appropriate for certain user-noticeable ongoing work under the applicable platform requirements, while persistent WorkManager work is another scheduling option; the correct choice depends on task requirements, execution duration, and platform rules. Do not claim that one API guarantees uninterrupted transfer or that a notification can bypass operating-system restrictions. The repository’s current download code exposes Progress, Completed, and Error states through a Flow; ModelManager exposes model states including downloading, downloaded, loading, ready, and error, plus byte/progress StateFlows. Those are code facts about the project, not evidence that Cove has a particular public notification channel or release distribution. A UI integration should map internal transfer and model states deliberately rather than show every raw error string. The notification should say which phase is underway and what the user can do, while avoiding raw model paths, private user prompts, credentials, or full token-bearing URLs. For long transfers, decide the notification policy before implementation. Is notification required only while a foreground service runs? Is work expected to wait for unmetered connectivity? Can the user pause or cancel? Should dismissal hide the card without cancelling, or is an explicit action required? How will the app handle a disabled channel? These decisions affect user trust. Never make swipe-dismiss mean cancellation unless the app clearly states and tests that behavior. Likewise, a cancel action should communicate whether it cancels only the current request, keeps verified partial bytes, or removes a candidate file. The exact byte-retention policy should follow artifact identity and resume validation, not notification convenience. Use a single state reducer for the in-app card and notification where possible. Both surfaces should read from the transfer owner and share state transitions, while their presentation can differ. Deduplicate repeated notifications for the same artifact so a retry updates the existing item instead of generating a noisy stream. A second model should receive its own identity and state. On notification tap, route to a detail screen using a stable work/artifact key, then reload current state from the owner; do not trust stale text embedded in the intent. If the task ended while the notification was delayed, present the terminal result rather than restarting the transfer. Testing needs a permission and lifecycle matrix: permission granted, denied, later revoked, channel disabled, app foreground and background, screen recreated, task waiting for constraints, transfer progress unknown, transfer paused, explicit cancellation, failure, verification, and ready. Test Android versions that exercise the permission flow and channel behaviors relevant to the app’s min/target SDK. Simulate process recreation only if the chosen work mechanism promises persistence. Confirm that hiding, dismissing, or disabling the notification does not lose work state. Check accessibility labels and notification text for concise, nontechnical phases; provide detailed diagnostics only in the app UI with redaction. ### Procedure 1. Define the authoritative transfer state and identity. Include artifact revision, scheduler state, byte counts and denominator source, verification, installation, and runtime readiness as separate fields. 2. Choose foreground service or persistent work from documented requirements. Verify current Android permission, foreground-service type, timing, and WorkManager constraint rules; do not select an API solely because it produces a notification. 3. Map state into notification and in-app surfaces. Provide a stable tap destination, user controls, disabled-channel fallback, and a truthful distinction between transfer finished and ready for use. 4. Specify dismissal and cancel semantics. State whether swipe dismissal hides only the notification; make explicit cancel a command to the transfer owner and document what happens to partial bytes. 5. Test permission/channel and lifecycle cases. Verify state consistency after grant/denial/revocation, app backgrounding, task stop, screen recreation, retry, verification failure, and terminal success. ### Acceptance criteria - Notification text is a projection of the current authoritative work state and never drives or invents that state. - Permission denial or channel disable leaves an in-app status and user recovery path; it does not imply cancellation or completion. - Transfer completion, verification, installation, and runtime readiness are separately represented. - Cancel and dismiss are distinguishable, artifact-scoped, and tested with the documented partial-file policy. ### Comparison | Surface or mechanism | Appropriate role | Boundary | |---|---|---| | Notification | Brief status and shortcut to current task | User can deny permission or disable channel; not authoritative storage | | In-app transfer screen | Details, recovery, and current state | Should observe shared work rather than start another writer | | Foreground service or WorkManager | Execution/scheduling mechanism selected by requirements | Neither guarantees every task runs uninterrupted under every OS condition | ### FAQ **Does a notification mean the model download will keep running?** Not by itself. Execution depends on the chosen service or work mechanism and Android restrictions. The notification communicates state; it does not grant scheduling privileges or guarantee uninterrupted transfer. **What if the user denies notification permission?** Keep the transfer’s authoritative state accessible in the app, explain any user action needed, and follow the task’s execution policy. Permission denial must not be interpreted as user cancellation. **Should dismissing the notification cancel the download?** Only if that behavior is explicit, accessible, and tested. Prefer separating “hide status” from a clearly labeled cancel action so a swipe does not unexpectedly discard work or partial data. **When may the notification say “ready”?** Only after the required artifact verification and installation/runtime checks complete. Reaching a byte percentage is not sufficient; if readiness has not been tested offline, avoid that claim.

A model transfer continues while notification visibility changes

A user starts downloading a model, backgrounds the app, then denies notification permission or disables its channel. The user later returns and needs to know whether work is waiting, active, cancelled, verifying, or ready without guessing from a missing notification.

Decision

Use the transfer owner as the source of truth and render its state in both notification and in-app surfaces. Keep notification permission and channel visibility separate from transfer execution and user cancellation.

Expected outcome

The user can recover the current task in-app, understands the phase and available action, and is never told a hidden or unverified transfer is complete.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Notification-state mapping
• Process recreation fixture
• Cancel and return test

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

To ensure consistency, the mapping between notification states and underlying download conditions should be explicitly recorded, alongside the process recreation fixture, and the cancel and return test results should be captured for direct comparison. These evidence items together establish a verifiable record of how each state is triggered and displayed, allowing the release wording to be grounded only in what has been observed and recorded rather than assumed from expected behavior.

1. Define one task state model. Represent waiting, running, stopped, cancelled, transferred, verifying, installed, loaded, and failed distinctly. Bind the state to a stable artifact key and keep byte-denominator provenance with the count.
2. Select an execution mechanism from requirements. Determine whether user-noticeable ongoing work, persistent scheduling, network constraints, or foreground interaction is required. Check the current platform requirements for permission and service types rather than assuming a notification makes work durable.
3. Render the same state in two places. Project owner state into the notification and in-app detail screen. Use a stable action destination that reloads current state; a notification should observe work and must not start an additional transfer.
4. Make controls and dismissal semantics explicit. Separate tap-to-open, pause, retry, cancel, and dismiss. Explain whether dismissal only hides the card and whether cancellation keeps a validated partial file. Route commands to the owner using the exact artifact identity.
5. Exercise denied and changed settings. Test permission denied or revoked, disabled channel, app background, constraint wait, unknown total, cancellation, verification failure, and success. Confirm the in-app recovery path and accurate phase after every transition.

Acceptance criteria

• Notification state always reflects the transfer owner and cannot start, complete, or cancel work by stale display alone.
• Users who deny permission or disable a channel can still inspect and recover the task inside the app.
• The UI distinguishes transfer, verification, installation, and runtime readiness.
• Dismiss and cancel have separate, tested behavior tied to the selected artifact.

Decision table

Failure patterns to prevent

• Showing completion before verification
• Losing user control in background

Common pitfalls to avoid include showing completion before verification has actually occurred and losing user control when the download moves into a background state. Release wording must be limited strictly to the recorded evidence, preventing any implication of readiness or completion beyond what the captured test results explicitly demonstrate, thereby protecting users from misleading status updates and preserving their ability to manage the download process at all times.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android persistent background work
• Android notification runtime permission
• Android notification channels
• Android WorkManager task management
• Android foreground service types

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions