App States
Xbox One supports fast switching between apps and the system’s user interface, and thus, Xbox One implements lifetime management of a process. A process is in one of five states: full, constrained, suspended, not running, or terminated. App code receives a notification event when the app’s state changes. An app should modify its behavior accordingly to the new app state. App states can be tested by using the Application Management (xbapp.exe) commands (suspend, resume, terminate, constrain, and unconstrain) to force an app to switch to one of the five process states.
The following table describes the five states of a process.
|
State |
Meaning |
| Full | The process is interacting with user, using the entire display, and has full access to the reserved system resources. The title has the following resources available:
- 6 CPU cores, plus 50% to 80% of a 7th core if resource configuration has been set to extended (see <mx:XboxSystemResources> Element for more information on enabling use of the 7th core).
- GPU allocations prior to the June 2014 XDK and Recovery: 90% of the GPU processing power is available (remaining 10% is reserved for system use)
- GPU allocations starting with June 2014 XDK and Recovery: In full screen, 92.5 to 95.5% of the GPU processing power is available (varaible amount from 0-3% used by the standard system GPU reserve and 4.5% used by the NUI GPU reserve).
In fill mode, 91.5% of the GPU processing power is available (4% used by extended system GPU reserve and 4.5% used by the NUI GPU reserve).
 Note |
|---|
Titles that do not use NUI Gestures (streams based on depth or IR) can disable the NUI GPU reserve and make use of the 4.5% NUI GPU reserve during gameplay. When not in gameplay (menus and lobbies), the title will not have access to the NUI GPU reserve. To disable the NUI GPU reserve, set the CoreApplication.DisableKinectGpuReservation Property to true.
Windows::ApplicationModel::Core::CoreApplication::DisableKinectGpuReservation = true;
|
|
Note |
|---|
| Titles can request that the Extended System Reserve mode is always enabled so that it is not necessary for titles to handle the complication of dynamic switches in and out of Extended System Reserve mode. Titles can request that the Extended System Reserve mode is always enabled by setting the mx:GpuAvailability element to fixed in the title's application manifest. |
- 5 GB of memory
|
| Constrained | The process is not interacting with user, occupies a reduced area of the screen (or is not visible at all), and has reduced access to the reserved system resources.Exclusive apps are always launched in constrained mode and become unconstrained when they respond to activation.Exclusive apps switch to constrained mode when the console switches to a full-screen shared app, when the display switches to Home, or when the console has called system UI (SystemUI).Exclusive apps will not be switched to constrained mode when the console switches to a snapped shared app or when system UI (SystemUI) is displayed.The title has the following resources available:
- 4 CPU cores
- 45% of the GPU processing power
- 5 GB of memory
When a title switches to constrained mode, CPU cores 4 and 5 are removed from the title reservation. Threads that were scheduled on those 2 CPUs will be folded, and instead scheduled on the remaining CPUs in the title reservation (0-3).Titles should register for the CoreApplication::ResourceAvailabilityChanged event to be notified when the available resources to a title have changed. When this event is raised, titles should examine the CoreApplication::ResourceAvailability property to determine whether the title is going into constrained mode or coming out of constrained mode. |
| Suspended | The process is not interacting with the user, not visible, and not executing; however, it is still resident in memory.The title has the following resources available:
- 0 CPU cores
- 0% of the GPU processing power
- 5 GB of memory
The CoreApplication.Suspending event is raised when an app is about to enter the suspended state.The CoreApplication.Resuming event is raised when an app is about to leave the suspended state.Titles will not receive events while suspended, and any events that would have fired will instead be dropped unless otherwise stated. Titles should re-query state on resumption, for example by enumerating users and controllers. Asynchronous operations that complete while a title is suspended will still invoke the completion callback when the title is resumed.Only one exclusive app can run at a time. Launching any other exclusive app will result in the existing exclusive app being suspended and then terminated.Xbox One exclusive apps must implement ID3D11DeviceContextX::Suspend and ID3D11DeviceContextX::Resume. When an app receives the Process Lifetime Management (PLM) Suspending event, it must call the Direct3D Suspend method. Otherwise the app will be terminated. When an app receives the PLM Resuming event, it must call the Direct3D Resume method. The title cannot render anything while the GPU is suspended. Calling any Direct3D method in between Direct3D Suspend and Resume will cause a crash. Both the suspend and resume calls must operate on the title's render thread, to ensure that GPU state is saved correctly by the suspend call.
|
Note |
|---|
| There is no user-scenario for directly suspending a foreground app. Users can switch to another app by going to home and then launching another app or deep-linking directly into another app. These actions will eventually result in the original app being suspended. |
|
| Not running | The process is not resident in memory, and the system has no historical information about the previous execution of the app. An app would be in this state in any of the following scenarios:
- The app has not been run since the console started.
- The app crashed during the last execution.
- The app did not properly suspend its process during the last execution, and it was forced to exit by the system.
|
| Terminated | The process is not resident in memory and, during the previous execution of the app, the app was successfully suspended and then terminated by the system. This means that the app had an opportunity to save its state before it was terminated; the next time the app is activated, it can load this previous state data and continue the user experience from the point of termination.Only one exclusive app can run at a time. Launching any other exclusive app will result in the existing exclusive app being suspended and then terminated. |
Testing App States
It is very important to test your application without Visual Studio attached. Process Lifetime Management (PLM) in Visual Studio is not the same as when the platform suspends your application when not running under Visual Studio. With Visual Studio attached, application behavior can change. As an example, apps will not receive sign-in / sign-out events upon Resume. It is up to the app to determine who is signed in when the app is resumed. The platform will not be queuing events. However, if you run your application under the Visual Studio debugger, the sign-in and sign-out events will queue and be raised when the application resumes. Your app should ignore those events upon resuming, and instead, determine who is signed-in when the resume event is raised.
See also
Application Model
White Papers - Process Lifetime Management for Xbox One (Developer Education Materials > All NDA Whitepapers)
Application Model Reference