You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Android versions come with broad range of different API versions. Currently, most of our testing uses only API 29 (e.g. Android emulators Ubuntu.2204.Amd64.Android.29.Open). However, in .NET 9, we support API levels 21 and higher. We should periodically test functionality on different API versions.
How
There is a prepared set of emulator queues with different API versions with naming: ubuntu.2204.amd64.android.<API> (where <API> goes from 21 to 32, if needed ask dnceng to include other API levels). To validate the functionality, we can open a PR which sends Android emulator jobs to all these different queues. An example of past PR used to validate different API versions #64341. Finally, we must verify the results from all queues to make sure the functionality is correct across supported API levels.
What
This verification makes the most sense to be done on the pre-release branch of dotnet/runtime. Optionally, we can also verify servicing branches if we await any issues. Throughout the release cycle, this validation should be performed periodically to prevent unexpected issues caused by un-tested API levels.
The text was updated successfully, but these errors were encountered:
Why
Android versions come with broad range of different API versions. Currently, most of our testing uses only API 29 (e.g. Android emulators
Ubuntu.2204.Amd64.Android.29.Open
). However, in .NET 9, we support API levels 21 and higher. We should periodically test functionality on different API versions.How
There is a prepared set of emulator queues with different API versions with naming:
ubuntu.2204.amd64.android.<API>
(where<API>
goes from 21 to 32, if needed ask dnceng to include other API levels). To validate the functionality, we can open a PR which sends Android emulator jobs to all these different queues. An example of past PR used to validate different API versions #64341. Finally, we must verify the results from all queues to make sure the functionality is correct across supported API levels.What
This verification makes the most sense to be done on the pre-release branch of dotnet/runtime. Optionally, we can also verify servicing branches if we await any issues. Throughout the release cycle, this validation should be performed periodically to prevent unexpected issues caused by un-tested API levels.
The text was updated successfully, but these errors were encountered: