Key Mapper is a free and open source Android app that can map a single or multiple key events to a custom action. The aim of this project is to allow anyone to map their buttons in any combination to anything.
You can help by suggesting ideas, notifying me of any bugs or contributing to the code directly. You can post suggestions and bug fixes in the Discord server, XDA thread, GitHub issues page for this repo. The latest cutting edge builds are uploaded to the #testing-builds channel in the Discord server everytime someone pushes to this repo.
To build and help with code stuff...
- Fork the KeyMapper repository (repo).
- Clone the repo to your device. It will clone to a folder called KeyMapper by default.
- Install Android Studio if you don't have it already. It is available for Windows, Linux and macOS.
- Open the cloned KeyMapper folder in Android Studio. Install anything Android Studio prompts you to install. E.g the gradle wrapper version used by KeyMapper or older Android SDK versions.
- Checkout (switch to) the "develop" branch.
- Make any changes then commit them to your forked repo then make a pull request!
Look at the help page in the wiki.
Take a look at the translations page in the wiki. Any translations will be appreciated. 😊
-
master: Everything in the latest stable release.
-
develop: The most recent changes. The app is potentially unstable but it can be successfully compiled. Merges into a release branch when enough has been changed for a new release.
-
release/*: Branched off develop. Beta releases for a particular release are compiled from here. Once the code is stable, it will be merged into master. No big changes should be made/merged here as the purpose of this branch is to make a release stable. By separating upcoming releases from develop, new features can be worked on in develop without affecting the upcoming release's code base.
-
feature/*: Any new changes currently being developed. Merges into develop.
-
hotfix/*: Any small, quick (atleast things which SHOULD be quick) changes that need to be made. Merge into develop and release. If there is no release already being worked on, quickly release a new version depending on how critical the issue is and merge the new release branch into master.
This project uses semantic versioning. e.g 1.2.3-alpha.1
- 1st digit: major release. Only incremented when a big enough change happens to the project.
- 2nd digit: minor releases. Incremented when a new feature or a few are added.
- 3rd digit: patches. Incrememtend after a hotfix or bug fix.
Additional labels can be used as a suffix. e.g "alpha".
The version code in the develop branch should always be the highest. Therefore, when a new version is released in the release branch, it should be incremented as well.
Format:
<issue id> <type>: <subject>
Every feature or bug fix commit should have an issue associated with it. This is a cue for the developer to plan what they are doing which improves efficiency. A feature should be split up into multiple tasks and each task should have its own commit. The feature should be developed on a separate branch and then merged into develop.
#100 feat: This a new feature
- feat: a new feature
- fix: a bug fix
- docs: changes to documentation
- style: formatting, missing semi colons, etc; no code change
- refactor: refactoring production code
- test: adding tests, refactoring test; no production code change
- chore: updating build tasks, package manager configs, version name changes, etc; no production code change
- release: a new release.
- website: stuff to do with the website.
The README, License, Credits, Changelog and Privacy Policy files should just be changed in the master branch.