Submitting Bugs, Feature Requests, and Pull Requests

Looking to contribute something to .NET for Android? Here’s how you can help.

Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.

These guidelines help the developers managing and developing this open source project to quickly and effectively resolve issues, prioritize enhancements and answer other questions.

Where to file an issue

We use Github Issues to track issues within this repository.

For general .NET for Android experience issues within Visual Studio or Visual Studio Code, please use the Report a Problem feature inside the IDE. You can find this by going to Help > Report a Problem within your IDE.

Using the issue tracker

The issue tracker is the preferred channel for bug reports, feature requests, and submitting pull requests.

• If you find your issue already exists, make relevant comments and use the Github’s “reactions” feature in place of a "+1" comment.

👍 - upvote

👎 - downvote

• If your issue is a question, then please ask it via Discord in the #android channel.

Issues and Labels

Our bug tracker utilizes several labels to help organize and identify issues.

Common Labels

• bug - Issues that are reproducible and confirmed. They will normally be closed when a pull-request that fixes them is merged.
• enhancement - Issues that represent a requested enhancement. The comments are a great place to exchange ideas about the enhancement and how it could be implemented.
• question - Issues that are best asked on Discord.
• need-info - Issues that lack information to be confirmed or worked on. These will be closed after 7 days of inactivity.

Area Labels

• android-designer - Issues dealing with the Android Designer in Visual Studio.
• Area: App+Library Build - Issues dealing with application or library building.
• Area: App Runtime - Issues dealing with application at runtime.
• Area: Bindings - Issues dealing with Android bindings and binding generator.
• Area: Documentation - Issues dealing with documentation.
• Area: Linker - Issues dealing with the Mono Linker.
• Area: Unit Tests - Issues dealing with unit test failures.
• Area: xamarin-android Build - Issues dealing with xamarin-android building.

For a complete look at our labels, see the project labels page.

Bug Reports

A bug is a demonstrable problem that is caused by code in the repository. Good bug reports are extremely helpful for our developers who maintain this project.

Guidelines for bug reports:

1. Validate your code - Ensure that your problem isn’t caused by an error in your code.
2. Use the GitHub issue search - Check if the issue has already been reported.
3. Check if the issue has been fixed - Try to reproduce the issue using the latest Preview.
4. Isolate the problem - Create a minimal, complete, and verifiable example to demonstrate the problem.

A good bug report shouldn’t leave others needing to ask you constantly for more information. Please try to be as detailed as possible in your report. Here are some tips that will help when filing an issue:

• Reproducible steps (1. 2. 3.) and what you expected versus what you actually saw.
• Images, animations, or a link to a video. Note: Images and animations illustrate repro-steps but do not replace them.
• A code snippet that demonstrates the issue or a link to a code repository we can easily pull down onto our machine to recreate the issue.
• Any respective build & deployment logs such as Diagnostic Build Output and adb logcat logs.
• Your environment's version information

Feature requests

Feature requests are welcomed. Before opening a feature request, please take a moment to find out whether your idea fits with the scope and goals of the project. It’s up to you to make a strong case to convince the project maintainers the merits of the feature. Please provide as much detail and context as possible.

Pull requests

Good pull requests of patches, improvements, new features, etc are great contributions. They should however remain focused in scope and avoid unrelated commits.

Before embarking on any significant pull request, please ask a maintainer if the scope of the pull request would be reasonable to merge into the project. Otherwise you can potentially waste a lot of time working on something that might not be relevant to the project’s goals.

While creating a pull request, please also include the intent for which you'd like the changes to land. By default, we ask that you pull against the master branch. However if you'd like to see a change in the next service release or preview release of Visual Studio, please communicate with a maintainer of this project to understand if the changes will be able to make the intended release.