Merge branch 'main' into alzollin/msstorecli-setup

Author: azchohfi

CONTRIBUTING.md

@@ -1,51 +1,7 @@
-# Contributing to UWP Conceptual Documentation
+# Contributing to this documentation
 
-Thank you for your interest in the Universal Windows Platform (UWP) documentation! We appreciate your feedback, edits, and additions to our docs.
-
-## Writing content
-
-Our documentation is written in Markdown, a lightweight text style syntax. If you're not familiar with Markdown, you can [learn the basics on GitHub](https://guides.github.com/features/mastering-markdown/). When unsure, you can always copy the formatting style from other pages in our docs.
-
-## Public contributions
-
-If you are **not** a Microsoft employee, you can contribute through the [public content repository](https://github.com/MicrosoftDocs/windows-uwp). Public contributions are appropriate for changes and clarifications to existing pages.
-
-### Editing a file
-
-If you're already in the public content repository, start by navigating to the file you want to change. From there, select the pencil icon above the displayed content to begin editing.
-
-Alternately, if you're viewing a published article on [Microsoft Learn](https://learn.microsoft.com/), you can select the **Edit** button on the upper-right portion of the page. This will redirect you to the associated source file in the repository.
-
-When you begin editing, GitHub automatically forks the official repo into your personal GitHub account, where you can make your changes. When you're done, submit a pull request back to the **docs** branch.
-
-### Pull requests
-
-After you submit your pull request, it is evaluated against a content quality checklist to ensure it meets our basic standards. If it passes, it is assigned to a member of the UWP documentation team for further review. If it fails, you'll be told what changes to make.
-
-The assigned reviewer(s) may approve or reject the PR, or work with you to make further changes.
+Thank you for your interest in contributing to our documentation! We appreciate your feedback, edits, and additions to our docs. Please see the [Microsoft Learn documentation contributor guide](https://learn.microsoft.com/contribute/) for information on how to do quick edits, get a local contribution environment set up, review open pull requests, and create quality issues, along with some "Microsoft writing essentials", the Learn site authoring pack for VS Code, and info about Hacktoberfest.
 
 ## Internal contributions
 
-If you are a Microsoft employee, you can contribute through the [private content repository](https://github.com/microsoftdocs/windows-uwp-pr). You can find guidance on using this repo in the [Windows Authoring Guide](https://review.learn.microsoft.com/windows-authoring-guide/uwp/?branch=main). Documentation on upcoming features must be contributed via the private repository only.
-
-### Editing a file
-
-As in the public repository, you can make small changes to the private repository in your browser, without needing to create a local clone. You **must** ensure that you are contributing on the correct branch. For more information about creating your personal branch, see [the instructions in the Windows Authoring Guide](https://review.learn.microsoft.com/windows-authoring-guide/uwp/conceptual/branches?branch=main).
-
-### Making substantial changes
-
-To make more extensive changes to an existing article, add or change images, or contribute a new article, create a local clone of the private content repo. Fore more information, follow [the instructions in the Windows Authoring Guide](https://review.learn.microsoft.com/windows-authoring-guide/uwp/conceptual/).
-
-### Pull requests
-
-When creating a pull request in the internal repo, make sure you're merging your personal branch into the branch it was created from.
-
-After you submit your pull request, it is evaluated with [PR Merger](https://review.learn.microsoft.com/help/contribute/prmerger-overview?branch=main) to ensure it meets our basic standards. If it passes, you can comment `#sign-off` to pass it to member of the UWP documentation team for further review. If it fails, you'll be told what changes to make before you can sign off.
-
-The assigned reviewer(s) may approve or reject the PR, or work with you to make further changes. Reviewers will not merge the PR until you have approved it yourself.
-
-## Using issues to provide feedback on UWP Conceptual documentation
-
-If you want to provide feedback on the docs instead of making edits yourself, you can [create an issue in the public repo](https://github.com/MicrosoftDocs/windows-uwp/issues). Select the **Issues** tab and select the **New issue** button. Be sure to include the topic title and the URL for the page. Your issue will be assigned to members of the UWP documentation team for review.
-
-* For internal issues, use the [WDG Content Request Tool](http://sesuw2-iis02a/WSCPubRequest/WindowsContentRequestTool.aspx).
+If you are a Microsoft employee, please contribute through the [private content repository](https://github.com/microsoftdocs/windows-dev-docs-pr).

hub/android/wsa/release-notes.md

@@ -6,13 +6,23 @@ ms.author: mattwoj
 ms.reviewer: mousma
 manager: jken
 ms.topic: article
-ms.date: 02/10/2023
+ms.date: 03/15/2023
 ---
 
 # Release Notes for Windows Subsystem for Android™️
 
 These release notes are based on updates to the Windows Subsystem for Android™️. For basic information on how to install and run Android™️ apps on Windows, see the Support article: [Installing the Amazon Appstore and Android™️ Apps](https://support.microsoft.com/windows/mobile-apps-and-the-windows-subsystem-for-android-f8d0abb5-44ad-47d8-b9fb-ad6b1459ff6c).
 
+## Build 2302.4000
+
+March 15, 2023
+
+- Stability improvements to graphics card selection
+- Updates to the Windows Subsystem for Android Settings app to include performance options for graphics cards
+- Docking and undocking with external monitors issues fixed with the subsystem
+- Fixes to apps with audio buffer issues
+- Android 13 security updates
+
 ## Build 2301.40000.4.0
 
 February 9, 2023

hub/apps/design/widgets/index.md

@@ -67,7 +67,7 @@ Content should dynamically refresh based on available context. It is up to date
 1. Your app can support multiple individual widgets. Determine the number of separate widgets you want to support so that each widget focuses on a specific purpose.
 1. Determine the content you want to include for each widget. A single widget can support three different sizes; small, medium, and large. For each widget, think about what content would bring the most value to users and your business needs. For each size from small to large, the purpose of the widget should remain the same, but the amount of information displayed should expand with larger sizes. We recommend that widget providers implement all widget sizes to give users flexibility when customizing the widget layout. 
 1. Think about the user interactions your widget will support. Users can click on the widget title or any click targets that you’ve defined on the widget. These interactions can activate deep-link shortcuts into your app or web site that take users directly to what they're interested in, so that they don’t have to navigate from the root of your app. Consider the different navigational models offered.  
-1. Apps must implement a widget provider that implements the back-end functionality to send your widget's layout and data to the widgets board to be displayed. Currently you can implement a widget provider using a packaged Win32 desktop app. Support for Progressive Web Apps (PWA) is planned for future releases. For more information, see [Widget service providers](../../develop/widgets/widget-providers.md).
+1. Apps must implement a widget provider that implements the back-end functionality to send your widget's layout and data to the widgets board to be displayed. Currently you can implement a widget provider using a packaged Win32 desktop app or a Progressive Web App (PWA). For more information on creating a Win32 widget provider, see [Widget service providers](../../develop/widgets/widget-providers.md). For information on PWA widget providers, see [Build PWA-driven widgets](/microsoft-edge/progressive-web-apps-chromium/how-to/widgets).
 
 
 

hub/apps/develop/widgets/widget-provider-manifest.md

@@ -16,7 +16,7 @@ In order to be displayed in the widgets host, apps that support Windows widgets
 
 The app package manifest file supports many different extensions and features for Windows apps. The app package manifest format is defined by a set of schemas that are documented in the [Package manifest schema reference](/uwp/schemas/appxpackage/uapmanifestschema/schema-root).  Widget providers declare their registration information within the [uap3:AppExtension](/uwp/schemas/appxpackage/uapmanifestschema/element-uap3-appextension-manual). The **Name** attribute of the extension must be set to "com.microsoft.windows.widgets".
 
-Widget providers should include the [uap3:Properties](/uwp/schemas/appxpackage/uapmanifestschema/elemnt-uap3-properties-manual) as the child of **uap3:AppExtension**. The package manifest schema does not enforce the structure of the **uap3:Properties** element other than requiring well-formed XML. The rest of this article describes the XML format that the Widget host expects in order to successfully register a widget provider.
+Widget providers should include the [uap3:Properties](/uwp/schemas/appxpackage/uapmanifestschema/element-uap3-properties-manual) as the child of **uap3:AppExtension**. The package manifest schema does not enforce the structure of the **uap3:Properties** element other than requiring well-formed XML. The rest of this article describes the XML format that the Widget host expects in order to successfully register a widget provider.
 
 ```xml
 <uap3:Extension Category="windows.appExtension">

landing/arm-docs/arm64ec-abi.md

@@ -45,7 +45,7 @@ This structure must be used to represent the CPU context while executing x64 cod
 
 It also implies that any Arm64 registers which cannot be fitted into the x64 `CONTEXT` must not be used, as their values can be lost anytime an operation using `CONTEXT` occurs (and some can be asynchronous and unexpected, such as the Garbage Collection operation of a Managed Language Runtime, or an APC).
 
-The mapping rules between Arm64EC and x64 registers are represented by the `Arm64EC_NT_CONTEXT` structure in the Windows headers, present in the SDK. This structure is essentially a union of the `CONTEXT` structure, exactly as it is defined for x64, but with an extra Arm64 register overlay.
+The mapping rules between Arm64EC and x64 registers are represented by the `ARM64EC_NT_CONTEXT` structure in the Windows headers, present in the SDK. This structure is essentially a union of the `CONTEXT` structure, exactly as it is defined for x64, but with an extra Arm64 register overlay.
 
 For example, `RCX` maps to `X0`, `RDX` to `X1`, `RSP` to `SP`, `RIP` to `PC`, etc. We can also see how the registers `x13`, `x14`, `x23`, `x24`, `x28`, `v16`-`v31` have no representation and, thus, cannot be used in Arm64EC.
 

uwp/audio-video-camera/system-supported-metadata-cues.md

@@ -168,7 +168,7 @@ In the **RegisterMetadataHandlerForEmsgCues** helper method, get an instance of
 
 In the handler for the **CueEntered** event, cast the data cue contained in the **Cue** property of the [**MediaCueEventArgs**](/uwp/api/windows.media.core.mediacueeventargs) to an [**DataCue**](/uwp/api/windows.media.core.datacue).  Check to make sure the **DataCue** object is not null. The properies of the emsg box are provided by the media pipeline as custom properties in the DataCue object's [**Properties**](/uwp/api/windows.media.core.datacue.Properties) collection. This example attempts to extract several different property values using the **[TryGetValue](/windows/windows-app-sdk/api/winrt/microsoft.windows.applicationmodel.resources.resourcemap.trygetvalue)** method. If this method returns null, it means the requested propery is not present in the emsg box, so a default value is set instead.
 
-The next part of the example illustrates the scenario where ad playback is triggered, which is the case when the *scheme_id_uri* property, obtained in the previous step, has a value of "urn:scte:scte35:2013:xml" (see [https://dashif.org/identifiers/event_schemes/](https://dashif.org/identifiers/event-schemes/)). Note that the standard recommends sending this emsg multiple times for redundancy, so this example maintains a list of the emsg IDs that have already been processed and only processes new messages. Create a new **DataReader** to read the cue data by calling [**DataReader.FromBuffer**](/uwp/api/windows.storage.streams.datareader.FromBuffer) and set the encoding to UTF-8 by setting the [**UnicodeEncoding**](/uwp/api/windows.storage.streams.datareader.UnicodeEncoding) property, then read the data. In this example, the message payload is written to the debug output. A real app would use the payload data to schedule the playback of an ad.
+The next part of the example illustrates the scenario where ad playback is triggered, which is the case when the *scheme_id_uri* property, obtained in the previous step, has a value of "urn:scte:scte35:2013:xml". For more information, see [https://dashif.org/identifiers/event_schemes/](https://dashif.org/identifiers/event_schemes/). Note that the standard recommends sending this emsg multiple times for redundancy, so this example maintains a list of the emsg IDs that have already been processed and only processes new messages. Create a new **DataReader** to read the cue data by calling [**DataReader.FromBuffer**](/uwp/api/windows.storage.streams.datareader.FromBuffer) and set the encoding to UTF-8 by setting the [**UnicodeEncoding**](/uwp/api/windows.storage.streams.datareader.UnicodeEncoding) property, then read the data. In this example, the message payload is written to the debug output. A real app would use the payload data to schedule the playback of an ad.
 
 :::code language="csharp" source="~/../snippets-windows/windows-uwp/audio-video-camera/MediaSource_RS1/cs/MainPage_Cues.xaml.cs" id="SnippetEmsgCueEntered":::
 

uwp/launch-resume/resume-an-app.md

@@ -67,7 +67,7 @@ MainPage::MainPage()
 
 The system suspends your app a few seconds after the user switches to another app or to the desktop. The system resumes your app when the user switches back to it. When the system resumes your app, the content of your variables and data structures are the same as they were before the system suspended the app. The system restores the app where it left off. To the user, it appears as if the app has been running in the background.
 
-When your app handles the [**Resuming**](/uwp/api/windows.ui.xaml.application.resuming) event, your app may be been suspended for hours or days. It should refresh any content that might have become stale while the app was suspended, such as news feeds or the user's location.
+When your app handles the [**Resuming**](/uwp/api/windows.ui.xaml.application.resuming) event, your app may have been suspended for hours or days. It should refresh any content that might have become stale while the app was suspended, such as news feeds or the user's location.
 
 This is also a good time to restore any exclusive resources that you released when your app was suspended such as file handles, cameras, I/O devices, external devices, and network resources.
 
@@ -122,4 +122,4 @@ For Windows Phone Store apps, the [**Resuming**](/uwp/api/windows.ui.xaml.applic
 
 * [App lifecycle](app-lifecycle.md)
 * [Handle app activation](activate-an-app.md)
-* [Handle app suspend](suspend-an-app.md)
+* [Handle app suspend](suspend-an-app.md)

uwp/launch-resume/suspend-an-app.md

@@ -133,7 +133,7 @@ The system doesn't notify an app when it's terminated, so your app must save its
 
 If you make an asynchronous call within your handler, control returns immediately from that asynchronous call. That means that execution can then return from your event handler and your app will move to the next state even though the asynchronous call hasn't completed yet. Use the [**GetDeferral**](/uwp/api/Windows.ApplicationModel) method on the [**EnteredBackgroundEventArgs**](/uwp/api/Windows.ApplicationModel) object that is passed to your event handler to delay suspension until after you call the [**Complete**](/uwp/api/windows.foundation.deferral.complete) method on the returned [**Windows.Foundation.Deferral**](/uwp/api/windows.foundation.deferral) object.
 
-A deferral doesn't increase the amount you have to run your code before your app is terminated. It only delays termination until either the deferral's *Complete* method is called, or the deadline passes-*whichever comes first*. To extend time in the Suspending state use [**ExtendedExecutionSession**](run-minimized-with-extended-execution.md)
+A deferral doesn't increase the amount of time you have to run your code before your app is terminated. It only delays termination until either the deferral's *Complete* method is called, or the deadline passes-*whichever comes first*. To extend time in the Suspending state use [**ExtendedExecutionSession**](run-minimized-with-extended-execution.md)
 
 > [!NOTE]
 > To improve system responsiveness in Windows 8.1, apps are given low priority access to resources after they are suspended. To support this new priority, the suspend operation timeout is extended so that the app has the equivalent of the 5-second timeout for normal priority on Windows or between 1 and 10 seconds on Windows Phone. You cannot extend or alter this timeout window.
@@ -150,4 +150,4 @@ A deferral doesn't increase the amount you have to run your code before your app
 
  
 
- 
+