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 make any button they use with their Android device do whatever they want.
You can help by suggesting ideas, notifying me of any bugs or contributing to the code directly. You can post suggestions and bug fixes by emailing me or posting in the XDA thread, Telegram channel or GitHub issues page for 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:
<type>: <subject [issue it is related to including the #]
body
footer
Every feature or bug fix commit should have an issue associated with it. This forces 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 developd on a sepearate branch and these commits should be squashed into a single commit when the branch is merged.
feat: This a new feature #100
Extra information about the feature goes in here. It should be wrapped to
roughly 80 characters.
- 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. Put issues it resolves in the footer. E.g "Resolves: #543"
The README, License, Credits, Changelog and Privacy Policy files should just be changed in the master branch.