Gboard Patches: a Morphe patch source that rewrites Gboard from inside

What this project actually is

Gboard Patches describes itself as Morphe patches for Gboard, with a mix of global usability improvements and Taiwan-focused enhancements. The overview calls it a public Morphe source for a curated set of Gboard enhancements, covering both global usability improvements and Taiwan-focused features for local input habits and day to day use.

The mechanism is patch-based rather than a fork. The repository is not a maintained copy of Gboard with changes committed; it is a set of patches and a build pipeline that applies them to a Gboard you supply. Morphe is the framework that does the applying, and the README carries a badge that offers an Add to Morphe action pointing at a URL that registers the repository as a patch source. That is the whole distribution model: you add the source to Morphe, and Morphe builds a patched Gboard for you.

The tree confirms the structure. There is a patches/ directory, a patches-list.json and a patches-bundle.json at the root, an extensions/ directory, a tools/ directory, a release-assets/ directory, a docs/ directory, and the Gradle files, settings.gradle.kts, gradle.properties and the gradlew wrappers.

Two JSON files at the root is a notable choice. patches-list.json and patches-bundle.json are the machine-readable description of what the source contains, which is how a patch source can be inspected without reading the patches themselves, and it is how the build knows what to apply and what to ship.

The licence is GPL-3.0 with a NOTICE file at the root, and the project has a CHANGELOG.md. The last push was on 2026-10-16, and the release tags show v3.13.0 on the same day, preceded by v3.13.0-dev.1 and v3.13.0-dev.2 two days earlier, which is the pattern of a project that builds and tests a release candidate before tagging it.

Two categories of change, and why the distinction matters

The README splits the feature list into two sections, and the split is the most informative thing in the document.

The first category is called Project-Built Features, and the description is explicit: features designed and built by this project rather than simply unlocking an existing Gboard flag. The second is Gboard Feature Unlocks, described as features already present in Gboard that are exposed by enabling hidden settings, rollout gates, or built-in behaviour.

That distinction is a real engineering one. An unlock is a configuration change. Google shipped the code, the behaviour is already there, and what is missing is either a settings toggle that is hidden behind a flag or a server-side rollout gate that has not reached your device. Turning it on is a matter of finding the right flag and writing it to the right store.

A built feature is new code. The clipboard enhancements, the web clipboard portal, the FTP server, the calculator and the frosted glass option are things that did not exist in Gboard and that this project wrote. That is a much larger undertaking, and it carries a much larger risk, because new code in a keyboard has access to everything you type.

The distinction also affects how you should read the list. An unlock behaves exactly as Google intended, so the risk is that Google removes the feature or changes the flag in the next update. A built feature behaves however the project implemented it, so the risk is in the implementation, and the project is the only party that can fix it.

The unlocks listed include AI writing tools with support for all languages, advanced voice typing with automatic punctuation, automatic punctuation for Traditional Chinese voice typing as a separate enablement because that path does not support advanced voice typing, OCR and scan text with Latin, Chinese, Japanese, Korean and Devanagari recognition backends, flick up on the English QWERTY keyboard to toggle uppercase, and inline autofill suggestions in supported contexts.

The Traditional Chinese detail is the clearest example of the Taiwan focus. It is not a separate input method so much as a set of local adaptations, and the long-press editing shortcuts patch is described as adding Select all, Undo, Copy, Cut, Paste and Redo to English QWERTY and Zhuyin, with an optional globe-key drag gesture that follows the same physical key positions across supported alphabet layouts.

The features the project builds itself

The built features are where the work is, and they fall into three groups.

The first group is clipboard work. The clipboard enhancements patch lets you extend retention time, item count limits, preview lines, the countdown and creation-time labels, the order index and the grid columns, and optionally render only the first 1,000 characters on each clipboard card. The last option is a privacy decision made concrete: a card shows a truncated preview, so a notification does not leak the whole of what you copied.

The Web Clipboard is the ambitious one in that group. It hosts a phone-powered portal that lets desktop browsers sync with Gboard over the same LAN, with a pairing code gate and an optional Quick Settings tile. The screenshots in the repository show a pairing gate and a conversation view. The pairing code is the interesting design decision, because a clipboard server on your network is a significant thing to expose and the code is what stops another device on the same Wi-Fi from reading it.

The second group is file transfer. The FTP Server patch hosts an FTP server on the phone so desktop FTP clients can browse, upload, download and resume transfers over the same LAN. It supports anonymous or password-protected access, a configurable control and passive port range, read-only mode, the sdcard or a user-selected folder as the root, live transfer progress, retained partial uploads, and an optional Quick Settings tile. The passive port range matters because FTP's active mode is awkward through a modern NAT, and the retained partial uploads matter because a phone's connection drops.

The third group is keyboard behaviour and appearance. The Floating Web Search opens a floating web page straight from the keyboard. The Custom Theme option imports custom ZIP themes and themes from the official Rboard repository. Frosted Glass adds live background blur and custom-theme transparency, on Android 12 and later devices that support cross-window blur, with a bundled theme such as Animal Black. Long-Press Editing Shortcuts and Toolbar Editing Buttons add the usual clipboard and undo actions to the long-press menu and to the toolbar, the latter draggable to the top toolbar. The Swipeable Custom Top Row opens customizable text and JavaScript slots by swiping the top row horizontally, which is the most open-ended of the set because it lets the user put their own script in the keyboard's UI. The Simple Calculator adds an inline calculator for arithmetic expressions typed in any text field, with the result appearing in the suggestion row and a tap replacing the expression or a long-press copying the result.

The rest are smaller: swipe down to dismiss the keyboard, the G logo on the spacebar, configurable rounded corners with separate top and bottom radii, an independent English globe key ignore interval for the post-typing language-switch delay, drag-and-drop reordering of the Emojis, stickers and GIFs panel, a dedicated symbols tab with a quick entry from the comma long-press popup, and an Incognito toggle in the Access Point toolbar that configures clipboard and voice typing availability while it is active.

Backup, restore and the raw flag stores

One built feature deserves separate attention because it is the one that protects everything else.

The Backup and Restore patch exports all Gboard Patches settings to a portable JSON backup and restores only the modules you select, with per-module and per-key results. The per-key detail is what makes it a diagnostic tool as well as a backup: you can see which individual settings were restored and which failed, rather than discovering that something did not take effect days later.

It also goes one level deeper than the project's own settings. It exports, compares and restores Gboard's raw PB and XML flag-store files. That is the layer where the unlocks actually live, and being able to see and compare those files directly means you can diff the flag state before and after a Gboard update, and reapply what was lost.

That is the real risk in this whole project, and it is worth naming. Most of the unlock features depend on Google writing a flag to a store. When Gboard updates, that store may be reset, the flag may be renamed, or the feature may be pulled. A patched Gboard that stops behaving the way it did yesterday is usually not a broken patch, it is a new Gboard version that moved the ground underneath it.

A tool that can export, compare and restore those raw files is therefore the difference between a project that is annoying to maintain and one that is maintainable. It also gives the user a way out, since a restore to a known state is available when a particular patch misbehaves.

Building the patch source and what the JSON files are for

The repository is a Gradle project, with gradlew and gradlew.bat wrappers, a gradle/ directory, settings.gradle.kts and gradle.properties. It also has an extensions/ directory, a tools/ directory and a release-assets/ directory, and a docs/ directory that holds the feature screenshots.

The patches-list.json and patches-bundle.json at the root are the part worth understanding. In a source where the deliverable is a patched application rather than a library, the source needs a manifest that says what it contains, which version of the target it applies to, and how the pieces relate to one another. A list file and a bundle file is that manifest split in two: the list enumerates, the bundle packages.

That structure matters because the target moves constantly. Gboard ships on its own schedule and the patch set has to be re-validated against each new version, which is why the release tags carry development versions before the final one. The dev tags v3.13.0-dev.1 and v3.13.0-dev.2 two days ahead of v3.13.0 are the build pipeline doing exactly that, and the CHANGELOG.md at the root is where the per-version differences are recorded.

The extensions/ directory suggests the project treats some features as optional units loaded into the patched build, and the tools/ directory holds the scripts that do the patching and packaging. Together with the release-assets/ directory, that is the shape of a source whose artefact is a downloadable build rather than a source archive.

The README also points to a Ko-fi link for the author, and a Morphe badge for adding the source, so the supported path for a user is to add the source in Morphe rather than to run the Gradle build by hand. The Gradle files are there for development and for anyone who wants to inspect the build.

Limits: what a patched keyboard inherits and what the README does not say

Several limits are worth being blunt about.

The first is that this is a patched Gboard, not Gboard. Anything the project does not patch, Gboard does as Google intended, and anything the project patches may behave differently from the Play Store version in ways the README does not itemise. The feature list tells you what was added. It does not tell you what was changed, and it does not promise that the patched build matches the stock build anywhere else.

The second is the dependency on the target version. Every unlock depends on a flag or a rollout gate in a specific Gboard build. When Google updates Gboard, those may be renamed, removed or reset, and the patch stops applying or stops doing anything. The Backup and Restore patch mitigates this rather than solving it.

The third is the security surface. A keyboard sees everything you type, and this project adds code to the keyboard. The Web Clipboard opens a network service on the phone with a pairing code, the FTP Server opens another with anonymous access as an option, and the Swipeable Custom Top Row executes user-supplied JavaScript inside the keyboard process. Each of those is a defensible feature, and each is a meaningful amount of trust being asked of the user. The README does not discuss the security model, the threat surface or how the pairing code is generated.

The fourth is the platform floor. Frosted Glass requires Android 12 or later and a device that supports cross-window blur, which is a hardware and OS capability as well as an API level. The OCR unlock depends on recognition backends for Latin, Chinese, Japanese, Korean and Devanagari, and the Traditional Chinese automatic punctuation is a separate enablement from advanced voice typing, so a user wanting both has to turn on two things.

The fifth is that the Taiwan-focused features are the reason the project exists in its current shape, and for a user who does not type Chinese they are inert. That is not a criticism, but it does mean the feature list mixes genuinely universal improvements with locally specific ones, and a reader has to sort them.

This patch source against the stock Gboard and against the other keyboard frameworks

Two comparisons make the choice clearer.

The first is against using stock Gboard with a third-party keyboard such as the two offered by Google itself. A stock keyboard, whatever it is, is supported, signed and updated by Google, and the advanced voice typing, the OCR and the writing tools features work in a way the vendor guarantees. The difference in approach is that the patched build makes Gboard's own features available to you, rather than replacing Gboard with a different keyboard. If you prefer how Gboard types and only want the OCR and the writing tools, the patch is the smaller intervention.

The second is against the ecosystem of custom keyboards built for the purpose, which is a large and mature category with its own advantages. Those give you a maintained application with the features you want, a privacy story you can read about, and updates that arrive on their own schedule. The difference in approach is that they are separate applications, so you lose Gboard's specific behaviour, and the data they collect is their own rather than Google's.

The honest case for this project is narrow and specific. The unlocks give you features that exist in Google's own code and work exactly as Google designed them, which is something no alternative keyboard can promise. The built features are the more interesting engineering but the more speculative investment, since they depend on the target and are maintained by one person.

There is also a category this project does not attempt, which is the other end of the scale: a keyboard that removes network access and telemetry entirely. A patched Gboard is still Gboard, with Google's services, and the patches add to that rather than subtract from it. If your concern is privacy rather than features, this is the wrong tool and the reasoning above does not apply.

Editorial conclusion

Adopt Gboard Patches if you use Gboard daily and want features Google ships but hides, such as OCR, advanced voice typing and writing tools, or want clipboard and file transfer conveniences that no stock keyboard offers. Do not adopt it if you need a keyboard that behaves exactly as the Play Store version, because the build is a patched Gboard and will differ from the official one in ways the README does not itemise. Verify first which Gboard version the release targets, that your Android version supports the features you want, such as the cross-window blur the frosted glass option needs, and that the licensing terms of the patched Gboard you end up running are ones you accept.

Frequently asked questions

Official sources

1. Issues
2. jasonwu1994/Gboard-patches on GitHub
3. License: GPL-3.0
4. README
5. Releases