Provide a way for terminals in store to explicitly block update or reboot

[huoyaoyuan]

Proposal: Provide a way for terminals in store to explicitly block update or reboot

Summary

Add an an element in packaged application's manifest, to declare that the app should not be terminated by system or store even they are "inactive". Doing so will block reboot.

Rationale

Inspired from microsoft/terminal#6726

Now, Windows Terminal and PowerShell have become store apps. Unlike mobile-like apps, terminals and consoles are unlikely able to restore their state after restarting.

For example, I used to run a long-running task in terminal while sleeping. I was detected "inactive" by the system, but my terminal is still working. Some day, the store killed and updated the Windows Terminal.

Even if it has completed it's job, I still don't want it to be restarted, because I need console logs.

Scope

Capability	Priority
Prevent Windows Terminal and PowerShell Core to be updated while working	Must

[ghost]

all packaged apps be it win32 or UWP suffer from this Packaged Apps Update issue. they just never save the current app data state during package updates and also never restarts itself after an update has been installed. so if an update has been installed all the unsaved data gets lost.😕

This is a pain and needs to be fixed ASAP.

I will like Project Reunion consider & provide something like :.

installing package updates (store or I myself locally through App Installer) ➡ check if the app is open ➡ if not open , apply update silently ||| or if open, save all the unsaved current working data/app state ➡ terminate the process & apply package updates ➡ restart the app itself and restore the all the unsaved current working data/app state. everybody becomes happy. 👍

[ptorr-msft]

Rather than a manifest entry, this would be better served as an API. For example, consider an app like Adobe Media Encoder that watches a folder and encodes files it sees there. While the app is not doing anything, it's fine to kill it and update (assuming it gets auto-restarted again) and I would be very upset if my machine failed to reboot just because there was an idle encoding app doing absolutely nothing. But once the app notices a file to encode, then it can say "I am busy; do not terminate me until I tell you I am done."

Of course there would likely be an uber-override for critical security bugs, and the user should still be able to close via red "X", Task Manager, etc.

[mdtauk]

Why focus this just on Terminals?

All apps should have the ability to only update on app restart. This new API should also be able to let the app display a message to the user saying that an app update is available, or the app will update next time it starts.

[ghost]

All apps should have the ability to only update on app restart. This new API should also be able to let the app display a message to the user saying that an app update is available, or the app will update next time it starts.

this☝ . now this is perfectly aligns with unpackaged regular win32 apps. couldn't say it myself any better.

[stevewri]

Aren't these two different APIs? 1) @ptorr-msft 's API to tell the system that an app is busy and shouldn't be interrupted to shut down (regardless of whether that's for update purposes or not); 2) @mdtauk 's API(s?) to check for updates, update only on app restart?

[stevewri]

The "app is busy" API is related to this issue: #129

[ptorr-msft]

There are already APIs to check for, and apply, updates - StoreContext.GetAppAndOptionalStorePackageUpdatesAsync.

The new feature request is the ability to say "hey, I'm busy right now!"

[prayaas-a]

Rather than a manifest entry, this would be better served as an API. For example, consider an app like Adobe Media Encoder that watches a folder and encodes files it sees there. While the app is not doing anything, it's fine to kill it and update (assuming it gets auto-restarted again) and I would be very upset if my machine failed to reboot just because there was an idle encoding app doing absolutely nothing. But once the app notices a file to encode, then it can say "I am busy; do not terminate me until I tell you I am done."

Of course there would likely be an uber-override for critical security bugs, and the user should still be able to close via red "X", Task Manager, etc.

And it wouldn't have to be a system restart but just an app restart in the case of Store updates. Once the app closes, it should be upgraded in the background automatically like how many apps with bundled installers like VS Code do. This would allow VS Code like apps to also adopt the Store as a delivery mechanism with minimal changes to the update scenarios. The Adobe Media Encoder background app example is still an issue, though, because a user might never close it manually. So perhaps there could be two options: one where an app specifies when it is busy and the other where the app says it's busy while it's open (with overrides of course) but the former is generally encouraged.

[sylveon]

Does ShutdownBlockReasonCreate not work?

[zadjii-msft]

Oh, this can probably get closed out. The Terminal resolved this on our side last year. From microsoft/terminal#6726 (comment):

<Package
  ...
  xmlns:uap17="http://schemas.microsoft.com/appx/manifest/uap/windows10/17"
  IgnorableNamespaces="uap uap17 uap16 mp">

  <Properties>
    <uap17:UpdateWhileInUse>defer</uap17:UpdateWhileInUse>
  </Properties>
  
</Package>

That property should be in the current¹ Insiders preview SDK. For reasons we (the Terminal) can't use that till it gets released as part of the stable SDK, later this year.

As we added in microsoft/terminal#16250

As documented: https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-uap17-updatewhileinuse

Footnotes

1. Current as of May 31, 2023. I don't know which SDK version that is exactly. Fall 2023? ↩

[huoyaoyuan]

I just get my Terminal restarted by store today. I'm on latest stable versions of both and not sure from what version they are taking effect.

[sylveon]

For reasons we (the Terminal) can't use that till it gets released as part of the stable SDK, later this year.

[zadjii-msft]

Sorry, that wasn't super clear. I wrote that comment in 2023. Terminal's been on that SDK version for a while now. As long as you're on a fairly new Windows build (23H2, whatever version that actually is), the store shouldn't kill the terminal anymore to force updates.

[zadjii-msft]

Ah, another clarification was made to me: Looks like Windows 11 builds 25399+ will be the first ones that actually have support for this. So Terminal is more than ready for it, but we need to wait for that to roll out broadly. So, it's available for apps to be ready to support it, but the OS builds just aren't broadly available yet.

[codendone]

Closing per the comments above.