Skip to main content
Wire Android is an open-source project and welcomes contributions from the community. This page explains what kinds of contributions are accepted, how to set up your environment, and what to include in a pull request.
Wire accepts only bug fixes and code improvements. New features, UI changes, and UX changes are decided and built by the Wire development team and cannot be accepted from external contributors.

Contributor Agreement

Before submitting your first pull request, you must sign the Wire Contributor Agreement. You can sign it electronically when you open your first pull request by filling in the required information in the PR description. You do not need to sign it again for subsequent pull requests from the same GitHub account.

Reporting bugs

If you find a bug, you can report it through one of two channels:
  • Support portal: Submit a ticket at support.wire.com. The Wire team will keep you informed about progress.
  • GitHub Issues: File an issue at github.com/wireapp/wire/issues. Include as much detail as possible to help the team reproduce the problem.

Opening a pull request

When your change is ready, follow these requirements before submitting:
1

Fill in the pull request template

Complete the PR template to the fullest extent possible. This helps the Wire team understand the proposed changes quickly.
2

Run tests and linters

All tests and linters must pass before submitting. See the Testing page for the relevant Gradle tasks.
3

Add tests for your changes

Include tests that cover the behaviour introduced or fixed by your change. This helps ensure the changes work as expected and do not regress.
All pull requests are reviewed by the @wireapp/android team, who are the code owners for this repository.

Code style

Wire Android uses Detekt for static analysis and code style enforcement. The pre-commit hook in .githooks/pre-commit runs ./gradlew detektAll automatically before each commit. You can also run it manually at any time:
./gradlew detektAll
You can also run the full static analysis suite:
./gradlew staticCodeAnalysis

Pre-commit hooks

The project uses pre-commit to enforce code quality checks on every commit. The configuration is in .pre-commit-config.yaml. The following hooks run on pre-commit:
HookPurpose
check-added-large-filesPrevents accidentally committing large binary files
check-case-conflictCatches filename case conflicts
check-merge-conflictDetects unresolved merge conflict markers
check-executables-have-shebangsEnsures shell scripts have shebangs
check-jsonValidates JSON files
check-tomlValidates TOML files
check-yamlValidates YAML files
mixed-line-endingFlags mixed line endings
end-of-file-fixerEnsures files end with a newline
trailing-whitespaceRemoves trailing whitespace
shellcheckLints shell scripts
On commit-msg, the conventional-pre-commit hook enforces Conventional Commits format. Accepted commit types are:
chore, build, refactor, fix, feat, test, ci, docs, wip, release

Installing pre-commit hooks

1

Install pre-commit

pip install pre-commit
2

Install the hooks

Run this from the repository root:
pre-commit install
This installs both the pre-commit and commit-msg hook types as defined in .pre-commit-config.yaml.

Git hooks (optional)

The repository also ships an optional Git hook in .githooks/pre-commit that runs ./gradlew detektAll before each commit. This is separate from the pre-commit framework hooks above. To enable it:
git config core.hooksPath .githooks
This hook is optional. If you prefer faster commits during active development, you can skip it and rely on CI to catch Detekt issues.

Commit message convention

Commit messages must follow the Conventional Commits specification. The commit-msg hook enforces this automatically once pre-commit is installed. Examples of valid commit messages:
fix: prevent crash when opening empty conversation
refactor: extract message mapper into separate class
test: add unit tests for MessageRepository
docs: update contribution guidelines

Build docs developers (and LLMs) love