Open-source project
HeliBorg/HeliBoard avatar
HeliBorg/HeliBoard

HeliBoard: an offline Android keyboard that took AOSP's and kept going

Customizable and privacy-conscious open-source keyboard

6,169 stars538 forksKotlinGPL-3.0

At a glance

What is it?
A GPL-3.0 keyboard for Android with no internet permission, editable text-file layouts, three distribution channels and one feature that still needs a closed source library.
Who is it for?
HeliBoard is the right pick for someone who wants an Android keyboard that cannot phone home, wants to edit their own layouts as text files, and would rather pick up a keyboard from F-Droid than an app store. It is the wrong pick if glide typing is a requirement, because that path depends on a closed source library the project cannot ship, and it is a demanding codebase to fork given 838 open issues and a GPL-3.0 licence.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 28 days ago.
What is it written in?
Mainly Kotlin, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Based on the AOSP keyboard, forked from OpenBoard

HeliBoard describes itself as a privacy-conscious, customizable open-source keyboard based on AOSP and OpenBoard. That starting point does most of the explaining. The AOSP keyboard is the one bundled with Android, so you are starting from Google's own Latin keyboard rather than from a blank design, and OpenBoard is the open source continuation of the old AOSP LatinIME project. The result is a keyboard whose behaviour is already familiar, with divergence bolted on deliberately rather than reinvented.

The privacy claim is stated in one sentence and is the most checkable thing in the README: the app does not request internet permission, and is therefore fully offline. That is a structural property rather than a policy promise. A keyboard that never asks for network access cannot leak what you type to a server no matter what its operators intend, which is a stronger guarantee than a privacy policy or a promise about data retention.

The repository is Kotlin, licensed GPL-3.0, with the default branch `main` and the last push on 2026-09-09. The tree shows a normal Android project layout with an `app/` module, a `tools/` directory, a `fastlane/` directory for release metadata, and an `art/` directory for artwork. It also carries three licence files: GPL-3.0 for the project, Apache-2.0 and CC-BY-SA-4.0 for whatever is covered by each of them, which is a detail worth resolving before you redistribute artwork or derived code.

Three ways to install it, none of them an app store

HeliBoard is not distributed through Google Play, so the install story is the F-Droid route, the GitHub release route, or IzzyOnDroid. Each has a different character.

F-Droid lists the package as helium314.keyboard, which is the conventional identifier for this project and the name to use when writing automation around it. F-Droid builds from source, which means you get the version in the F-Droid metadata rather than whatever the maintainer last uploaded, and that the build is reproducible by someone other than the author.

The GitHub releases route is the direct one, and the README puts a download badge near the top for the latest APK. That is the fastest path and the one most likely to be current, but it also means you are installing a binary that a person built.

IzzyOnDroid is the third option, an alternative repository that indexes and signs APKs from elsewhere. It sits between the two: you are still taking a prebuilt binary, but from a service that tracks upstream rather than from the project's own release page.

Whichever you pick, the same warning applies, and it is not an Android keyboard warning so much as an input method warning: a keyboard sees everything you type, including what you type into password fields. HeliBoard's answer to that is the missing internet permission. That is a meaningful reduction in exposure, and it is not the same as a keyboard with no access to your input at all.

Layouts are text files you can edit and share

The feature that separates HeliBoard from a stock keyboard is layout customisation, and it is done with plain text files. The README points to a `layouts.md` file at the repository root for the format, and explains that layouts can be saved, copied and shared the way theme files can. Custom keyboard layouts apply both to the main layout and to the special layouts reachable from advanced settings.

There is a constraint that catches people out. Custom keyboard layouts are only available when use system languages is disabled. That makes sense internally, because the system language set drives which layout HeliBoard picks, and a user override would conflict with it, but the README does not spell out the interaction prominently and it is the first thing to look at if layouts appear to be ignored.

Themes work in parallel and follow the same save and share model. From the adjust colors screen you can export and import a theme, share individual custom colors in a dedicated discussion category, and pick up collections from community repositories such as Star-Trowa/heliboard-themes and PickleHik3/droid-tings. There is also a third-party layout editor referenced in the README, Roccobot's Layout Maker, for people who would rather not hand-edit text.

Also on the personalisation side: emoji search that can follow the system day and night setting on Android 10 and later, dynamic colours on Android 12 and later, one-handed mode, split keyboard, number pad, and backup and restore for settings plus learned words and history.

Glide typing is the feature that needs a closed source library

This is the part of the README that deserves a straight reading, because it is the one place where the offline, no-permission guarantee meets a limitation. Glide typing is listed as available only with a closed source library, and the library is not included in the app, because the project's position is that there is no compatible open source library available.

The README then documents two ways to obtain it: extract it from GApps packages, where it sits in the swypelibs set, or download it from a specific file in the OpenBoard repository, using the raw link on GitHub. So the feature works, and the project tells you precisely how to get the missing piece, but the honest description is that a headline capability is sourced from somewhere else and is not something you get from the repository.

Dictionary support has its own sharp edge in the same feature list. You can build your own dictionaries or take them from the maintainer's aosp-dictionaries repository, with quality varying, and extra dictionaries for emojis or scientific symbols can serve suggestions. For Korean layouts, though, suggestions only work with one specific dictionary file, because the tools in that dictionary repository cannot generate working Korean dictionaries themselves. If you type Korean, that is the constraint to plan around.

Other features on the list: multilingual typing, clipboard history, and a number pad. There is also a wiki with an FAQ and a page on hidden features, which is where behaviour not listed above is documented.

Version 4.1 and what recent releases reveal

The release notes read like a maintained fork with a large user base, which is what 838 open issues and a steady release cadence suggest.

Version 4.1 shipped on 2026-08-30 with three changes listed: better behaviour when pasting current clipboard content, fixes for layouts set to no language, and a fix for manual shift failing after certain characters when gesture typing. All three are correctness fixes in areas users touch constantly, and the third is the kind of bug that only shows up after enough real typing.

The 4.1 beta from 2026-08-26 is where the visible features landed. It added a D-Pad, with associated overhauls in preparation for it, allowed key repeat to be used as the long-press code for toolbar keys and popups, made key repeat the default long-press code for arrow keys, improved the clipboard hint and fixed it disappearing in some text fields, updated settings icons, made popup hints display more consistently, tuned numpad key widths to line up with the number layout, added a separate colour type for the clipboard suggestion, and fixed a case where toolbar keys sometimes disappeared.

Version 4.0 on 2026-07-10 updated the Bengali dictionary and made a change worth understanding technically: it uses a fake CTRL+V instead of `KeyEvent.KEYCODE_PASTE`, because the real paste key event is ignored by some apps. That is a workaround for app behaviour the keyboard does not control, and it is a good illustration of the kind of problem a keyboard maintainer actually spends time on.

A governance note appears in the README's contributing section: do not use LLMs to generate issue reports, though assistance with translation is fine if disclosed. There is a separate `AI_USAGE.md` file setting out the detail, and translations run through Weblate, with pull requests that edit translations turned down because they conflict with Weblate.

Editorial conclusion

HeliBoard is the right pick for someone who wants an Android keyboard that cannot phone home, wants to edit their own layouts as text files, and would rather pick up a keyboard from F-Droid than an app store. It is the wrong pick if glide typing is a requirement, because that path depends on a closed source library the project cannot ship, and it is a demanding codebase to fork given 838 open issues and a GPL-3.0 licence. Two things to check first: whether your language has a working dictionary, since Korean layouts need one specific dictionary file, and whether you need layouts.md, because custom keyboard layouts only work once use system languages is switched off. Version 4.1 shipped on 2026-08-30 and the last push was on 2026-09-09.

Frequently asked questions

Is HeliBoard safe to use?

The design addresses the main risk with a keyboard, which is data leaving the device: HeliBoard does not request internet permission and is fully offline, so it has no channel to send what you type. A keyboard still sees all of your input including password fields, so the remaining question is how much you trust the build, which is why F-Droid, the GitHub releases and IzzyOnDroid are all offered as install routes. The project is licensed GPL-3.0.

What is HeliBoard?

A customizable, privacy-conscious open-source keyboard for Android, written in Kotlin and based on the AOSP keyboard with OpenBoard as the upstream project. It adds editable text-file layouts, theming, emoji search, clipboard history, one-handed mode, split keyboard, a number pad and backup and restore, and it publishes no GitHub releases history but does tag versions such as 4.1.

How do I get HeliBoard installed on my phone?

There is no app store listing. You can install the package helium314.keyboard from F-Droid, download the latest APK from the project's GitHub releases page, or use the IzzyOnDroid repository that indexes and signs APKs. F-Droid builds from source, while the other two give you a prebuilt binary.

Official sources

  1. HeliBorg/HeliBoard on GitHub
  2. Issues
  3. License: GPL-3.0
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/heliborg-heliboard.svg)](https://hysenlabs.com/projects/heliborg-heliboard)