Submission Validator Quality Checks

The types of problems that Submission Validator identifies will grow and evolve over time in order to work toward the goal of smoothing the way from submission, through certification and to market.

Submission Validator runs the following quality checks:

Available Version

Submission Validator checks to ensure that the version installed is the most current and correct version. If it is not, there will be a failure logged in the Submission Validator output log, and that failure message will contain a link to download the correct version.

<component>Available Version Check</component>
<failure>A required update to Submission Validator is available. XDK users must download from 
http://go.microsoft.com/fwlink/?LinkId=393356. ADK users must download from http://go.microsoft.com
/fwlink/?LinkId=393357. Download and install the update, then rebuild the package. Contact your 
Developer Account Manager for assistance.</failure>

Approved GameOS

Submission Validator checks that the GameOS (for exclusive titles) and any optional components from the XDK are from the same release of the XDK and that they are an approved version for use in released titles. If the version is not on the approved or deprecated list, a failure will be included in the validator log.

<failure>The GameOS included in this package is not an approved version. Use only 
supported GameOS versions according to the Approved Libraries page on the Developer 
Network Portal</failure>

If the version is found to on the deprecated list, a warning will be included in the validator log indicating that this is only valid for content updates for titles originally released on that deprecated version.

<warning>The GameOS included in this package is not approved for new title submissions. 
This version is allowed only for Content Updates where the original release used this 
version. Use only supported GameOS versions according to the Approved Libraries page on 
the Developer Network Portal</warning>

If the versions of the components don’t match each other, or if the version is not on the approved or deprecated lists, then a failure will be logged, such as this example:

<failure>The GameOS version does not match the version of other Microsoft components 
included in this package. Use only components from the same XDK release. Refer to the 
Approved Libraries page on the Developer Network Portal</failure>

Note Submission Validator may not complete its validation checks if the computer on which it is running cannot access online information, such as if the PC has no internet access, is blocked by a firewall or has no network connectivity at all.

Change in the connected storage quota limit check

If the mx:ConnectedStorage element appears in the AppXManifest and includes a change in the connected storage quota limit, the following warning will appear in the log:

mx:ConnectedStorage element specifies a change in connected storage quota limit. This requires a certification exception.
    
Contact your Developer Account Manager

Mismatched Chunk Contents

Checks that executable (EXE and DLL) components are separate from other files (assets, etc.) in the chunk layout. This corresponds to the best practice to minmimize download sizes for future updates. When this situation is detected, a warning like the following will appear in the Submission Validator log file.

<component>Mismatched Chunk Contents Check</component>
<warning>Chunk 1000 contains a mixture of files with executable data and files without executable data. 
To optimize for future Content Updates to executables, you are advised to place files with executable 
content into their own chunks. If you are packaging an update to an existing title, ignore this warning 
for any chunks which you are not adding/modifying in this update.</warning>

Launch Marker in Final Chunk for Content (DLC)

To ensure proper operation in all scenarios, Content packages must end with the update alignment chunk (like other packages) and that final chunk must be marked with the launch marker attribute. If the final chunk doesn’t include the launch marker, it is possible that the package could be tested correctly but cause problems for end users in some cases.

<failure>Content Packages require final layout chunk to include attribute marker="Launch"</failure>

Control Characters in Descriptive Strings

Ensure that none of the name, publisher, or other descriptive strings in the AppXManifest.xml contain \n, \r, \a or other C style string formatting control characters. If any of these characters are present, you will see a failure such as this in the log file:

<failure>String Properties_DisplayName contains one or more invalid control characters.</failure>

Additional Resources.Pri Files

Checks that no additional Resources.Pri files exist in other directories of the layout. As with AppXManifest.xml, only the one in the root is used, but having multiple copies could lead to confusion about which one is correct and what the developers’ intent is concerning these other files.

This parallels a similar check for additional copies of AppXManifest.xml and as in that case, additional copies result in a failure in the Foreign Files Check section of the log:

<failure>D:\path\mytitle\mytitlesubdirectory\resources.pri</failure>

Required Update of XCAPI.dll

An issue was identified relating to the block ordering in certain conditions in the application containers. This problem could lead to larger than expected content updates for titles and applications. Submission Validator explicitly checks for this issue by checking the version of the installed XCAPI.dll in the ADK or XDK \bin folder. This version number is reported in the log:

<component>Tools Check</component>
<XCAPI_version>6.2.9873.0</XCAPI_version>

If your XDK installation requires an update, this message will appear in the log:

<failure>Package will not be created. Update required for XCAPI.dll. XDK users must download from http://go.microsoft.com/?linkid=9840470. ADK users must download from http://go.microsoft.com/?linkid=9840484. Contact your Developer Account Manager for assistance</failure>

If an update is required, the XVC will not be created by MakePkg. Go to the appropriate URL in the failure message to get the Zip file containing the updated component. Extract the XCAPI.dll file and copy it to your ADK or XDK \bin folder, overwriting the previous version. Then run MakePkg again.

For more details regarding this issue, please consult the release notes contained in the Packaging Update Zip file.

Missing Resources.pri File

Applications are not required to be localized, but if an application does not include a Resources.Pri file in the root (same location as the AppXManifest.xml), this warning will appear in the Foreign Files Check section of the output log:

<warning>Non-localized app: 'resources.pri' is missing</warning>

Presence of Required NUI Database Files

If the Microsoft.Kinect.dll is included in the project and the kinectFace capability is included in the manifest, Submission Validator will check that the NuiDatabase folder is present with FaceAlignment.bin, FaceDetector.bin, and FaceOrientation.bin. These files can be found in the XDK \Redist directory. If these files are not found, this warning is added to the log in the MS Component Versions section:

<warning>Title includes the Microsoft.Kinect.dll and specifies the 'kinectFace' capability but does not include required NUI databases 
(FaceAlignment.bin, FaceDetector.bin, FaceOrientation.bin) for Kinect face detection. If your title uses other face detection, this 
warning can be ignored</warning>

Network Violation

Submission Validator checks for the following issues in the mx:XboxNetworkingManifest section of the AppXManifest XML:

KinectAudio or KinectGamechat Not Declared Together

Detects if either the kinectAudio or kinectGamechat capability is declared in the AppXManifest.xml but not both. If either of these capabilities is declared in the manifest, both must be. Submission Validator logs a failure if one of the two listed capabilities is present without the other.

Kinect pipeline manifest version compatibility

Submission Validator does a check to ensure the vision, speech, and audio pipelines are all compatible.

Greater than 4GB persistent local storage

Titles are allowed to use up to 4GB of Persistent Local Storage. If they require more an exception is required.

Appdata.bin Older than AppXManifest.xml

Submission Validator does a simple check based on file date/time and logs a warning if the appdata.bin file appears to be older than the AppXManifest.xml. This check catches situations where last minute changes are made to the manifest but appdata.bin was not regenerated. This is based on file date/time, it is an indicator, not a definitive check of the file contents.

Output package contains non-contiguous blocks

Submission Validator reports a failure if there are non-contiguous blocks in the output package. If anti-virus software or indexing software is running on the PC being used to build the package, then is it is possible to end up with non-contiguous blocks in the package which can result in content update issues at a later date.

Cross title Connected Storage Access Declaration

Submission Validator detects situations where titles are accessing connected storage associated with a differentcross title.

Ratings

The ratings declared in AppXManifest.xml are displayed in the Validator log and a warning will appear in the log if the AppXManifest.xml file contains no rating information.

One Application in Package

Submission Validator now validates packages only contain one application per package.

Layout Update Alignment Chunk

To avoid unnecessary size increase in future content updates for your title, all exclusive resource apps, content packages and shared resource apps with more than one chunk defined are required to include an alignment file as the final package chunk defined in the layout XML file. This chunk must have an ID of 1073741823. Your layout XML files should include this block of XML as the final chunk:

<Chunk Id="1073741823">
  <FileGroup DestinationPath="\" SourcePath=".\"     
  Include="Update.AlignmentChunk"/>
</Chunk>

The file Update.AlignmentChunk must exist in the indicated SourcePath and be exactly 1 byte. The content of the file is not used or checked in any way.

Maximum Package Size

Submission Validator checks to ensure the package does not exceed the maximum package size of 49,900,000,000 bytes.

Foreign Files

One of the problems encountered in reviewing submissions for the Xbox 360 program was the inclusion of various files with the submission, generally accidentally, that should not be part of a retail title.

The foreign files check uses the layout XML file to check all files brought into the title package for particular file names and extensions that are not allowed in the package. This check is based on the file name only, not on the contents of the files. The disallowed files include extensions related to source and debug files, Thumb.db, extraneous appxmanifest.xml files other than the one in the root, and the full list of Xbox One operating system files that cannot appear in title packages. This check is used to validate the Xbox Requirement XR-003, “Title Quality for Submission.”

The following table shows the file types and extensions that are not allowed in the submitted title package:

File type Extensions
Source code related files .c .cpp, .cs, .lib, .h, .obj
Debug/Symbol information files .pdb, .sym
Legacy binary files .xbe

We recognize the potential for a title to legitimately use almost any imaginable file extension and that this could lead to potential conflicts with the extensions checks. If this is an issue for your title, please alert your Developer Account Manager.

If you feel you have an exceptional case that requires a file to be included in your title package for which you are receiving a “failure” message in the Submission Validator log, you should consult with your Developer Account Manager.

The following example shows the log output showing failures in the Foreign Files check:

<component>Foreign File Check</component>
<failures>
  <failure>c:\MyTitle\loose\bar.cpp</failure>
  <failure>c:\MyTitle\loose\MySubDir\example.h</failure>
  <failure>c:\MyTitle\loose\MySubDir\PDBs\BlockedFiles\foo.pdb</failure>
</failures>
<filecount>3</filecount>

Binary Scan

Xbox One binaries (EXE and DLL) files must be built for AMD64 and be native code only. Currently, managed code binaries are not supported on the platform. The binary scan check examines each EXE and DLL file that will be included in the title package and ensures it meets these requirements. This check is used to validate XR-003, “Title Quality for Submission.”

The Binary Scan section is also where each EXE and DLL file is checked for dependencies that are blocked for security reasons on retail consoles. Generally, this takes the form of linking to a debug version of a platform file, PIXEvt.dll, or Xbox Studio.

The following example shows the log output showing failures in the binary scan check. The first two failures are the result of an EXE being linked to two files that are not allowed for retail consoles. The third failure is a managed EXE file. The final failure is a non-AMD64 native code DLL file:

<component>Binary Scan</component>
      <dumpbinlocation>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\dumpbin.exe</dumpbinlocation>
      <failures>
   <failure>Non-retail dependency in file c:\MyTitle\loose\ExeWithDebugDependencies.exe: MSVCR110D.dll</failure>
  <failure>Non-retail dependency in file c:\MyTitle\loose\ExeWithDebugDependencies.exe: PIXEvt.dll</failure>
  </failures>
  <failure>Managed: Not AMD64: c:\MyTitle\loose\MySubDir\ABC.exe</failure>
  <failure>Not AMD64: c:\MyTitle\loose\MySubDir\XYZ.dll</failure>
</failures>

Developers should ensure such debugging-focused dependencies are excluded from release builds of binaries to be included in a submission package.

Microsoft Component Versions

With Xbox One, much of the platform surface area has been encompassed in the Game OS (for exclusive partition titles) or the System OS (for shared partition apps). There are, however, a set of Microsoft-supplied binaries that are redistributed with titles. These files and their approved versions are listed on the Approved Libraries page on the Xbox Game Developer (XGD) site.

The Submission Validator checks the versions of these files to ensure any of the optional DLLs are of matching versions. It will also capture the Version ID of the Game OS that is being packaged into the XVC for an exclusive partition title. It is important that developers check the versions against the published approved library information before submitting.

Submission Validator will also extract the version information for the optional Kinect and Xbox Services DLLs, if your title includes them.

The following example shows the version information that appears in the Submission Validator log file:

<component>MS Component Versions</component>
<component name="GameOS">60BBA05C-22F0-4452-84B6-DD278594716E</component>
<component name="Microsoft.Xbox.Services.dll">6.2.9878.0</component>

Manifest

The manifest check examines the application manifest (AppXManifest.xml) for a number of potential problems. Each problem area appears as a separate section of the validator log.

ActivatableClassId entries

Duplicate ActivatableClass ID entries in the windows.activatableClass.inProcessServer extensions will cause a failure to be reported.

XboxSystemResources entries

Duplicate XboxSystemResources entries will cause a failure to be reported.

Link protocol

Xbox One apps are generally not permitted to register non-default protocol handlers.

Every Xbox One title automatically has a link protocol created for it. This protocol name is ms-xbl-[titleID in Hex]. Protocol registration that would appear in the Extensions section of the application manifest looks like this example which registers two protocols:

<Extension Category="windows.protocol">
  <Protocol Name="my-custom-protocol" />
</Extension>
<Extension Category="windows.protocol">
  <Protocol Name="other-protocol" />
</Extension>

Note The default protocol registration does not appear in the application manifest.

Submission Validator adds a warning to the log if a non-default protocol handler is detected in the application manifest:

<warning>Manifest contains link protocol registration, generally not allowed. Contact your Developer Account Manager. Protocol: your-protocol-name</warning>

Unless an exception has been granted for the title in question, this will lead to a rejection after submission. Engage your Developer Account Manager early in your development process if your title requires the use of a non-default link protocol. This check is used to validate XR-003, “Title Quality for Submission.”

Namespace/Schema Usage

The manifest must include a Package element that references both the global AppXManifest schema and the Xbox One-specific schema namespaces.

<Package xmlns="http://schemas.microsoft.com/appx/2010/manifest" xmlns:mx="http://schemas.microsoft.com/appx/2013/xbox/manifest" IgnorableNamespaces="mx">

Submission Validator will also check for appropriate usage of the “mx:” namespace qualifier on the following elements:

For many schema and namespace related errors, MakePkg will detect the problem as part of the pre-check, display an error message, and stop building the package before the Submission Validator even starts examining the files. In the event that MakePkg did not detect the error, Submission Validator will detect the error, and the failure would appear in the validation log. See the “AppXManifest Schema Changes” developer blog post listed in the Additional resources section.

Capabilities

At the time of publication of this white paper, the only capabilities allowed for Xbox One application manifests are:

As an aid for the functional certification test process at Microsoft, the list of claimed capabilities will be extracted to the validation log and appear as:

<capabilities>
  <capability>kinectFace</capability>
  <capability>internetClientServer</capability>
</capabilities>

The Submission Validator will check that only these capabilities are referenced in the manifest. If any other capabilities are claimed, even if they are valid on other Windows-based platforms, the validator log will contain this failure:

<failures>
  <failure>Invalid capability: internetClient. Check for correct 
      case and namespace.</failure>
</failures>

Note Capability names are case sensitive.

As with the schema and namespace, some errors related to the capabilities may be detected by MakePkg before the full validation begins. In this case, MakePkg reports an error and terminates. Errors detected by Submission Validator will appear in the validation log.

See the Xbox One developer documentation for the applicability and usage of these capabilities. See also the “AppXManifest Schema Changes” developer blog post listed in the Additional resources section.

Background Audio

Background audio is defined not as background music or audio within the context of a title, but rather the ability of a title to continue to play audio while the app is not active or visible on the screen. Because of the potential to create negative user experiences, this ability is restricted to specific system-level apps on Xbox One. Titles are generally not permitted to do this, and it would be unusual for a title to implement such a feature.

If Submission Validator detects a declaration for background audio in the application manifest, the following error will appear in the validator log:

<failure>Manifest includes Background Audio, generally not allowed. Contact your Developer Account Manager</failure>

Unless an exception has been granted for the title in question, this will lead to a rejection after submission. Engage your Developer Account Manager early in your development process in the unlikely event that your title requires the use of background audio as described above. This check is used to validate XR-003, “Title Quality for Submission.”

Image Properties

Xbox One apps must have four images referenced in their manifest and the files included in their package. Refer to this excerpt of an example AppXManifest.xml file:

<Applications>
  <Application Id="App" Executable="Sample.exe" EntryPoint="Sample.App">
    <VisualElements DisplayName="SampleApp" Logo="Logo.png" WideLogo="WideLogo.png" Description="SRA1" ForegroundText="light" BackgroundColor="#464646">
      <SplashScreen Image="SplashScreen.png" />
      <mx:ViewStates>

The following table shows the required image pixel dimensions:

Image Identifier Pixel Dimensions
Logo 208 x 208
SmallLogo 100 x 100
WideLogo 480 x 480
SplashScreen – Exclusive partition title 1920 x 1080
SplashScreen – Shared partition app 620 x 300

All images must be 24 bits-per-pixel + alpha .png files. Sometimes these are referred to as 32 bits-per-pixel, 32 bits-per-pixel ARGB, etc.

Downloadable Content (DLC)

The format for a DLC package manifest is slightly different in a few ways, notably related to ContentPackageVisualElements. When the Submission Validator identifies a DLC manifest, it checks the images and structure of the ContentPackageVisualElements tag in the same way that similar checks are performed on the VisualElements tag of a non-DLC package. The AllowedProduct ID is also checked and if the ID value is “00000000-0000-0000-0000-0000000000”, the following warning will appear in the log:

<warning>AllowedProduct ID 00000000-0000-0000-0000-0000000000 is not valid for submission</warning>

See also

Make Package (makepkg.exe)

Title Packaging and Streaming Installation

Xbox Requirements (XRs)