KeyMapper: turning spare buttons on Android into anything you want

A remapper with a wider input list than the name implies

The repository description gives the whole project away in one line: an Android app to remap the buttons on your devices. The README opens with the slogan version of the same idea, then gets to the specifics.

The input list is broader than Key Mapper suggests. It covers every phone button, and the README spells out volume AND the side key rather than leaving you to guess whether the power button is in scope. It covers game controllers, naming D-pad, ABXY and most others. It covers keyboards, mouse buttons, headsets and headphones, and the fingerprint sensor. The README adds that most devices are already supported with new ones added over time, and asks to be told when yours is not working so it can be prioritised.

One exclusion is stated with the same directness as the features: joysticks and triggers (LT, RT) on gamepads are not currently supported. If you want to map an analog stick or an analog trigger from a controller, that is the gap you will hit, and it is the most likely one for a pad-to-Android user to want closed.

There is a second answer to running out of buttons, and it is the more unusual of the two. Key Mapper will let you design your own on-screen button layouts and remap those just like real keys. Those synthetic buttons then become triggers like any hardware button, so a crowded mapping does not have to stop at the edges of the phone.

The project itself is unremarkable in the good way. Kotlin, GPL-3.0, 2673 stars and 260 forks, with badges for both Google Play and F-Droid at the top of the README so you can take it outside Google's store if you prefer.

Triggers, actions and constraints, in that order

The README explains what a key map is through three headings, and the order matters because it mirrors the way you build one.

TRIGGERS decide how a map fires. A long press, a double press, press as many times as you like, and keys combined across different devices, including the on-screen buttons from the previous section.

ACTIONS are what the map does. The README counts over 100 individual actions and names the categories: screen taps and gestures, keyboard inputs, opening apps, controlling media, and sending intents directly to other apps. You choose the delay between each action and can set an action to repeat, which is how you automate something slow instead of tapping through it.

CONSTRAINTS decide when a map is allowed to run at all. Only in one specific app, only when media is playing, only on the lockscreen. Without constraints every map is global, which is rarely what you want once you have more than one.

Two things sit underneath that model and are worth understanding before you install. The repository topics include accessibilityservice and android-accessibility, which is where the reach comes from: an accessibility service can observe and inject input events in a way an ordinary app cannot. It is also the reason the permission deserves a moment of thought before you grant it. Separately, the 4.4.0 changelog refers to auto starting Expert Mode, a second mode that sits below the normal interface, and fixes crashes in that path were part of a bugfix release rather than a feature one.

One default is friendlier than most. Version 4.3.1 set do not remap as the default in settings, so a fresh install does nothing at all until you deliberately turn a behaviour on.

Three releases in ten weeks, and what each one changed

The three most recent releases sit close together, dated 2026-08-11, 2026-09-12 and 2026-09-21, with the last push landing the same day as the newest one.

Version 4.3.1 is the small one. It added a display resolution constraint and a ringer mode constraint, and set do not remap as the default. The two constraints are narrower rules of the same kind as the existing ones: the first limits a map to a particular screen size or density, the second ties it to silent or vibrate.

Version 4.4.0 is the interesting one, because its fixes are the kind only a project with this many users finds. It ships Reduce app killing tips for Xiaomi, Redmi and Poco devices, which is a vendor-specific survival guide rather than a code change. It lets you sort key maps by enabled or disabled, adds a cycle keyboard language action, and adds a custom seek amount for the media step actions so a volume key can skip ten seconds instead of five. It adds export and import of key maps on Android TV, which is the only mention of TV anywhere in the release history.

Three fixes in the same release are more revealing than the features. Auto starting Expert Mode sometimes crashed. Shell commands failed when they carried Windows line endings, which is what happens when a command is composed on a desktop and pasted into a phone field. And screen tap, swipe and pinch actions now scale to display resolution, so a gesture defined on one device no longer lands in the wrong place on another.

Version 4.5.0 then extends the constraint system rather than the trigger system. Constraints can be grouped, and each group gets its own AND or OR logic, which is how you express a rule like only in the camera app while media is playing. It adds a vibrate action with custom duration or haptic effects, an action to cycle through enabled keyboards, a constraint that inspects notifications, and turn off, duplicate and rename operations applied to actions.

What the directory layout tells you about the implementation

The tree is short enough to read in one pass, and a few names carry most of the information.

The directory called evdev/ is the clearest signal. evdev is the Linux input event interface, and it is how you read a keyboard, a mouse or a gamepad as a stream of events rather than as a device. Having it at the top level explains how one codebase handles all those input types, and it also explains the gamepad joystick exclusion, since analog axes are reported through a different path than the buttons listed in the README.

Alongside it sit sysbridge/, systemstubs/ and system/, which together suggest the app does more than user-space event injection, with a bridge component and a layer of stubs for the system pieces it does not own. The remaining modules are library-shaped and ordinary: api/, base/, common/ and data/ hold the public surface, shared code and the packaged definitions that actions and constraints are built from.

Two files at the root are worth a second look. The default branch is develop rather than main, so a clone gives you the integration branch rather than a stable release line. And a Gemfile sits next to build.gradle.kts and settings.gradle.kts, because fastlane/ is there too and release automation to the Play Store is written in Ruby, separately from the Gradle build that produces the app.

The README itself is short and links out rather than duplicating, pointing to keymapper.app for documentation and to a Discord community for day to day questions. Contributor guidance lives on the same site.

A repository tree also shows what is absent. There are no example mapping files checked in, and no sample configuration to read, so the fastest way to understand a working map is to build one in the app.

Distribution, translations and a busy issue tracker

Key Mapper ships two ways, and the README shows both badges side by side: the Google Play listing and an F-Droid package under io.github.sds100.keymapper. The F-Droid route matters because the project's licence is GPL-3.0 and the build is reproducible from the repository, so nothing about your remapping data depends on a store account.

Funding is handled without a feature gate. The README carries Ko-fi, Liberapay and Stripe donation links, which is a reasonable arrangement for an app distributed free on two stores with no advertising and no account.

Translations run through Crowdin, and seven languages are listed as available: Czech, Spanish, Polish, Brazilian Portuguese, Russian, Slovak and Simplified Chinese. That is a decent spread for a utility of this kind, and the fact that the badges read proofreading progress rather than a hard count suggests the strings are community maintained rather than professionally translated.

The number that deserves your attention is 184 open issues. Against 2673 stars that is a high open ratio, and for an accessibility-service app it is close to structural rather than alarming. The input surface is every button on every device, so support requests arrive in a steady stream, many of them specific to one handset model or one vendor's Android skin. The README's request to report unsupported devices so they can be prioritised is the mechanism, and the Xiaomi tips in 4.4.0 are evidence of the same pressure showing up in the release notes.

Documentation is the piece to read before you configure anything. The repository README is an introduction, and keymapper.app is where the trigger, action and constraint options, the device list and the contributing guide actually are.

Editorial conclusion

KeyMapper is a broad remapper with an unusually honest README, which states the supported input list and the one conspicuous gap in the same breath, and asks for reports on devices that fail rather than quietly dropping them. The trigger, action and constraint model is what makes it more than a volume-key hack, since constraints can now be grouped with their own AND and OR logic and remaps can be switched off, renamed and duplicated in bulk. Two things deserve a closer look before you commit. The 184 open issues reflect an input surface that spans every button on every device, so a model that is not on the supported list may never work, and the joysticks and triggers on a gamepad are the one documented exclusion. And the app's reach depends on Android granting an accessibility service, a permission that is powerful enough to be worth understanding before you toggle it rather than after.

Frequently asked questions

Official sources

1. keymapperorg/KeyMapper on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases