Document update lifecycle risks and production readiness

[Copilot]

Assess the updater across lifecycle completeness, developer experience, potential bugs, and architecture. Distinguish source-supported defects from integration responsibilities and usability improvements.

• Source-based assessment: Add a detailed English review and Chinese summary, with revision-pinned evidence and prioritized recommendations.
• Production boundaries: Document Android-only scope, installer-handoff semantics, missing restart/rollback guarantees, and required host safeguards.
• Risk inventory: Cover retry gaps, cancellation state, disposal races, HTTP-client ownership, credential forwarding, UI-thread dispatch, and dependency limitations.
• Documentation accuracy: Align English prerequisites with .NET 10 and Android API 26+.

Assessment: a foundation for hardened Android integrations, not a turnkey cross-platform updater. Runtime behavior is unchanged; identified defects remain open.

• Fixes Code Review Prompt for GeneralUpdate.Avalonia #18

[JusterZhu]

@copilot Fix each issue and defect one by one as you sorted them out.

[Copilot]

@copilot Fix each issue and defect one by one as you sorted them out.

Implemented B1–B5 and S1 in 6b3ce29: retries/resume, cancellation and failure states, client ownership, safe shutdown, timeout classification, and credential-origin/HTTPS/redirect protections. Added callback isolation and fail-closed pre-checks. License metadata corrected in f1c1f1c; documentation now tracks fixes and remaining host/platform responsibilities.

All 160 core tests pass; independent review found no remaining significant issues. Android build is blocked locally by the missing workload, CI requires approval, and final automated validation hit its time limit. Installer completion/restart/rollback, APK identity preflight, signed manifests, and a runnable Avalonia sample remain explicitly documented follow-ups—not claimed as implemented.

[JusterZhu]

@copilot Has the automatic upgrade process formed a closed loop now? Is the coding interface developer-friendly for integration?

[Copilot]

@copilot Has the automatic upgrade process formed a closed loop now? Is the coding interface developer-friendly for integration?

Not a complete closed loop yet; integration is improved, but not plug-and-play.

Upgrade lifecycle

The implemented path is check → download/resume/retry → size/SHA-256 verification → launch Android installer. The fixes harden this path, but LaunchInstallerAsync.Success means only that the intent launched. The state remains Installing; AddListenerUpdateCompleted is a stage notification, not proof the app was upgraded (source).

Still missing from the library: persisted update tracking across process death, actual installation-result reconciliation, next-launch version confirmation, and application-level recovery/rollback. Ordinary Android installation also requires platform/user approval; these fixes do not provide silent installation. The host must persist the intended version and confirm it on the next launch to close the outcome loop.

Developer integration

Reasonably usable as a low-level Android service: CreateDefault, three async operations, structured results, progress/failure events, injectable services, and safer cancellation/disposal reduce integration work.

Not yet a turnkey developer experience: the host still configures FileProvider/install permissions, supplies UI-thread dispatch, coordinates the three calls, and handles installation confirmation. There is no runnable Avalonia sample. Completed naming, pre-check true = skip, and cancellation returning a result during execution but throwing while waiting on the gate remain API friction points (integration guide).

Recommended next step: a host-facing coordinator with persisted pending-update state and next-launch reconciliation, clearer stage-specific notifications, and a runnable Android/Avalonia sample validated on devices. Automatic rollback needs a separate platform/data-migration design.

The 160 passing core tests validate the fixes—not real-device installation/restart. Current CI still requires approval. So I would describe this as a hardened integration foundation, not a fully closed-loop production updater.

[JusterZhu]

@copilot Complete the missing core capabilities.

[Copilot]

@copilot Complete the missing core capabilities.

Implemented in 1e2685c.

• CreateCoordinator / RunAsync orchestrate check → download/verify → durable intent → installer handoff.
• ReconcileAsync confirms the host-reported installed version after process recreation; handoff alone never means Updated.
• RetryAsync rechecks/reverifies safely; changed targets cannot overwrite unresolved intent. AbandonAsync explicitly clears tracking.
• Added private atomic persistence, workflow locking, typed lifecycle events, cancellation/disposal handling, and English/Chinese integration guidance. Existing APIs remain compatible.

Validation: 57 focused tests and all 217 core tests pass; Android Release build succeeds. Independent correctness/security reviews found no issues; CodeQL reports zero alerts. The bundled automated reviewer was unavailable. The existing build-dependency advisory remains documented.

The host must invoke reconciliation at startup/installer return and supply its actual installed version, permissions and UI dispatch. This adds the core version-confirmation loop—not silent installation, automatic restart/rollback, or application-health verification. Device testing and a runnable Avalonia sample remain outstanding.