ReteKey IME
com.retekey
Zapstore _@zapstore.dev Republished from GitHub / F-Droid by the Zapstore main account.
First release: Aug 11, 2026, 51 total releases.
Most recent release: Sep 26, 2026.
Appears in 0 app stacks.
0 sats / 0 zaps received in the past year.
Sats Received
Underlying data available via MCP: app_zaps, app_releases.
Zap Count
Underlying data available via MCP: app_zaps, app_releases.
Releases
- Sep 26, 2026 0.2.0
- Sep 25, 2026 0.1.199
- Sep 25, 2026 0.2.0-legacy**No motion now covers the memo and clipboard panels too.** - With **No motion** on (ReteKey settings → Feedback), the memo's buttons and tick boxes no longer play Android's ripple when pressed, a tick appears at once instead of drawing itself in, and the memo and clipboard lists no longer glow when scrolled to an end (#15). The keys were already still; now the panels are too. - The version steps to 0.2.0. Nothing is removed and no setting changes; it is simply the next release. Downloads: `retekey-0.2.0.apk` (Android 9+) · `retekey-0.2.0-legacy.apk` (Android 4.0+).
- Sep 23, 2026 0.1.196
- Sep 23, 2026 0.1.199-legacy**Shift stays as you left it, and an unplugged keyboard lets go of its keys.** - **A finger that slides off Shift takes its press back.** Shift (and Ctrl, Alt, Meta) take effect the moment the finger lands, so that fast typing shifts the right letter. If that finger never lifted — it slid off the keyboard, the window went away, the page was rebuilt under it — the modifier stayed armed and shifted whatever you typed next. Now the press is undone: off if it was off, locked if it was locked. If you did type a key while holding it, that counts as having used it, as before. - **A keyboard unplugged mid-chord no longer leaves Ctrl "held".** Physical modifiers are now remembered per keyboard, so one keyboard's key release cannot let go of another's, a keyboard that is removed takes its keys with it, and leaving a text field clears them. If a release is missed anyway, the next ordinary key says what is really held and the keyboard believes it — no more arrows from the action bar arriving as Ctrl+arrow. Downloads: `retekey-0.1.199.apk` (Android 9+) · `retekey-0.1.199-legacy.apk` (Android 4.0+).
- Sep 22, 2026 0.1.194
- Sep 21, 2026 0.1.192
- Sep 21, 2026 0.1.194-legacy**The keyboard keeps its hands off password fields, and starts cleanly before the phone is first unlocked.** - **Nothing reads a password field.** Typing, including Korean composition, works there as before. What stops is the helpers that looked at the field's text: select-word, the kana ゛゜小 key, the Hanja key, and the 나랏글 stroke on a character already written. This applies to every password field, including a terminal that declares itself one. - **A copy made in a password field stays out of the clip list.** Copying from a visible-password field used to add the text to the keyboard's clip history. Now copies made while a password field is in use, or just after leaving one, are not kept, including when the keyboard catches up with the clipboard later. The same goes for fields that ask for no personalised learning, such as an incognito tab. - **No crash before the first unlock.** After a restart, Android can start the keyboard before the phone has been unlocked for the first time, and the keyboard used to crash reaching for its settings, which cannot be read yet. It now starts on default settings, records nothing, and switches to your own settings once you unlock. Your data is never copied outside its encrypted storage to make this work. Downloads: `retekey-0.1.194.apk` (Android 9+) · `retekey-0.1.194-legacy.apk` (Android 4.0+).
- Sep 19, 2026 0.1.189
- Sep 19, 2026 0.1.192-legacy**Paste where the editor's shape lies, and the layout format shown as itself.** - **Paste in an SSH client (issue #9, reopened).** An app can be a terminal on the screen and an ordinary editor to the connection — an SSH client whose field reports a cursor was handed the editor's own paste, which such a view ignores while reporting success. Paste, and paste only, now also asks whether the app is known as a terminal by name, and types the clipboard when it is. Everything else is still decided by the editor's shape, so a plain text field inside a terminal app keeps behaving like a plain text field. - **The layout format, shown rather than described (issue #11).** The settings screen now carries a whole example layout — header and all — as selectable text under the layout controls. A test parses exactly the string the screen shows, so the example cannot drift away from what the app reads. Downloads: `retekey-0.1.192.apk` (Android 9+) · `retekey-0.1.192-legacy.apk` (Android 4.0+).
- Sep 19, 2026 0.1.191-legacy**The share door is split in two** (issue #11, @llsant). Text shared to ReteKey is now always kept inside ReteKey, and a layout is installed through an entry of its own — *Install a ReteKey layout* in the same share sheet, or by opening a **.rkl** file from a file manager or an attachment. Nothing is decided by what the text begins with any more, so a note that starts with the layout header is a note, and a layout whose first line was mangled is reported as a layout that could not be read rather than quietly kept. Neither door touches the system clipboard, and neither needs a permission: an opened file is read through the one grant the opener gives. Checked by the unit suites on both flavours (the routing itself is a pure class with its own tests) and by lint at both floors.
- Sep 18, 2026 0.1.185
- Sep 18, 2026 0.1.189-legacyThree adjustments after a phone's-eye look at v0.1.188. - **The light theme is grey rather than white.** Key faces were the lightest neutral there is, which read as a sheet of paper; they are one step down the ramp now, over a slightly darker ground — by hand and under Material You alike. - **The box that shows what you typed starts see-through** (60%), so the row underneath reads through it. The character on top stays crisp at any setting. - **No ⚙ in front of the settings entries** on the app's own screen. Downloads: `retekey-0.1.189.apk` (Android 9+) and `retekey-0.1.189-legacy.apk` (Android 4.0+); `retekey.apk` and `retekey-legacy.apk` are the same builds under a stable name.
- Sep 17, 2026 0.1.186-legacyA 나랏글 fix: the syllable before a stroke no longer disappears. Typing 신재님, the 신 vanished the moment ㅈ was made — ㅈ is ㅅ with a stroke, and the stroke asks for the syllable the ㅅ closed back. The keyboard did that with three calls (clear the composition, delete a character, compose again), and an editor that runs them out of order deletes the character before the composition and never puts it back. It now takes the text back by **marking it as the composing region** and replacing it in place — nothing is deleted, so nothing can be lost. Editors that will not mark a region still get the old way, and terminals and remote desktops are unchanged. Downloads: `retekey-0.1.186.apk` (Android 9+) and `retekey-0.1.186-legacy.apk` (Android 4.0+); `retekey.apk` and `retekey-legacy.apk` are the same builds under a stable name.
- Sep 16, 2026 0.1.184-legacyText you share into ReteKey is kept by the keyboard and typed on demand — the system clipboard is never told (issue #10). - **Share text to ReteKey** from any app's Share menu, or from a text selection's own menu. It appears at the top of the **Clip** list under *Kept in ReteKey*; tap it and it is **typed** into whatever you are writing in. - **Nothing is copied.** The clipboard is neither read nor written for kept text. On some makers' ROMs a keyboard that is not even on screen reads every copy and files it in a history you cannot turn off; text that was never copied cannot be read that way. No permission is involved — a share is the sending app's own decision. - **It ages out on your clock**: ten minutes, an hour, a day, or until you remove it (settings → *Clipboard and kept text*). Twenty items at most. - **Follow the system clipboard** is a setting there too, on by default. Turn it off and the keyboard never looks at the clipboard at all — sharing becomes the only way text reaches it. Downloads: `retekey-0.1.184.apk` (Android 9+) and `retekey-0.1.184-legacy.apk` (Android 4.0+); `retekey.apk` and `retekey-legacy.apk` are the same builds under a stable name.
- Sep 16, 2026 0.1.174
- Sep 16, 2026 0.1.179-legacyThe phonetic page, rearranged by sound — and three things the keyboard was asked for. - **IPA by sound (issue #11):** every symbol now sits at the letter it sounds like, the way X-SAMPA reads a keyboard: `e` types **ə** (holding ɛ ɜ ɚ ɝ), `a` **æ** (ɑ ɐ ɶ), `t` **θ**, `d` **ð**, `s` **ʃ**, `z` **ʒ**, `n` **ŋ**, `j` **ʤ**, `r` **ɹ**, `v` **ʌ**, `o` **ɔ**, `u` **ʊ**, `i` **ɪ**, and the last cell of the bottom row carries the stress and length marks ˈ ˌ ː ˑ. Every key holds the rest of its family, so the alphabet is one page and a hold deep. - **Shift on that page is the plain letters**, where QWERTY has them — a transcription is full of ordinary p, t, k, s, and a page that could not type them would send you to another layout every other character. That row's last key is `/`, holding `[` and `]`. A physical keyboard types both pages in the same places. - **The action bar is inside the keyboard's height again.** Turning it on no longer pushes the keyboard further up into the app; if the rows feel short with the bar on, raise the keyboard's height. - **The 12-key pads keep Shift in one place:** beside Meta on both 천지인 and 나랏글, whatever the pad is showing. 천지인's **Next** moved down beside ㅇㅁ, where the full stop used to be — the full stop and comma are on the key beside Enter anyway. - **Notepad → Send:** types the note, or the part you selected, into the app at its cursor. It goes out as typed input rather than a paste, so a terminal or a remote desktop takes it like anything else the keyboard types. Downloads: `retekey-0.1.179.apk` (Android 9+) and `retekey-0.1.179-legacy.apk` (Android 4.0+); `retekey.apk` and `retekey-legacy.apk` are the same builds under a stable name.
- Sep 15, 2026 0.1.170
- Sep 15, 2026 0.1.174-legacyAction-bar keys chord and repeat, and the clipboard list follows Android's clipboard. - **Action bar keys chord with any modifier:** the bar's arrows, Home/End, page keys and your text and key-combination slots now combine with whatever modifier is down — the bar's own Ctrl/Alt/Meta, the keyboard's Ctrl/Alt/Meta/Shift, or one held on a physical keyboard. A text slot of a single letter or digit becomes that key: Ctrl + a slot of `c` copies; Shift alone types a capital. - **Hold to repeat:** the arrows, Home/End and page keys now repeat while held, as text slots already did. A one-shot Ctrl stays on for the whole hold. - **Clipboard list:** anything copied in any app now appears in Clip, the current clipboard is at the top when you open it, and picking a clip also puts it on the clipboard. Clips an app marks as sensitive (password managers) are not kept. - **Fix:** the first copy recorded after the keyboard restarted could replace the saved clip list with just that one clip. Checked on an emulator. Not yet checked by hand on a real phone.
- Sep 14, 2026 0.1.166
- Sep 14, 2026 0.1.170-legacyThe composing strip for terminals now actually shows. - **Terminals (issue #7):** in 0.1.169 the strip that shows the syllable you are building never appeared on a phone. Android kept the area around it hidden. It now shows above the keys while a syllable is being built, and goes away when it is sent. - **Floating keyboard:** the syllable is shown in the floating panel's own title bar, between the arrow and close keys, instead of a strip at the top of the screen. The panel no longer moves or changes size while you type. - **Every app:** since 0.1.169 a hidden strip could keep an empty band above the keys; it no longer takes any room. Checked on an emulator by drawing the keyboard window into a picture, docked and floating. Not yet checked on a real phone, or with a physical keyboard plugged in.
- Sep 13, 2026 0.1.169-legacyTerminals now build the syllable on the keyboard's own strip. - **Terminals (issue #7):** a terminal has no composing region, so until now each syllable was typed into it and taken back with every stroke. That is what caused the flickering cursor, the stray erase characters and the syllables dragged by Termux's arrow buttons. Now the syllable you are building is shown on a strip above the keyboard and sent to the terminal only once it is finished. Nothing is taken back any more. - **The trade:** the syllable is not visible inside the terminal until it closes. If you prefer the old way, turn off **Terminals → Show the syllable on the keyboard's strip** in ReteKey settings. - Backspace inside a syllable edits the strip; with nothing on it, it is a real backspace. Keys that end a syllable (Space, Enter, arrows from a physical keyboard, leaving the app) send it first. - A pause no longer ends a syllable in a terminal: 바, a pause, then ㄷ gives 받 again. - Remote desktop is unchanged from 0.1.168. Checked in Termux on an emulator. Not yet checked on a real phone: the strip itself, the strip with a physical keyboard plugged in, and the floating keyboard while the strip is shown.
- Sep 12, 2026 0.1.163
- Sep 11, 2026 0.1.166-legacy**A fix to v0.1.165, reported within hours of its release.** Typing Korean into Termux's toolbar text field — the input box you reach by swiping the extra-keys row — left every half-built syllable on screen, separated by a character most fonts draw as a box. That character is DEL, the erase character v0.1.165 started using to redraw a syllable in a terminal. A terminal reads DEL as "erase"; an ordinary text box just stores it, and Termux's toolbar field is an ordinary text box. The keyboard was treating every field in Termux as a terminal because the app is on a short list of terminal apps. That list now follows the same rule as everything else: an app on it counts as a terminal only where the editor reports that it does not know where its cursor is. Termux's terminal still composes Korean as you build it; its toolbar field is a text box again. Unchanged and known: Termux's own arrow buttons move the cursor without telling the keyboard, so deleting right after using them can take back the wrong block, and the terminal cursor flickers while a syllable is redrawn. ---
More…
**v0.1.165 의 결함 수정. 릴리즈 몇 시간 만에 신고받았습니다.** Termux 의 부가 키 줄을 옆으로 밀면 나오는 텍스트 칸에 한글을 치면, 만들다 만 음절이 글꼴이 네모로 그리는 글자를 사이에 두고 모두 남았습니다. 그 글자는 DEL, 즉 v0.1.165 가 터미널에서 음절을 다시 그리려고 쓰기 시작한 지우기 문자입니다. 터미널은 DEL 을 "지워라"로 읽지만 평범한 글자 칸은 그냥 저장합니다. Termux 의 그 칸이 평범한 글자 칸입니다. 키보드는 Termux 가 터미널 앱 목록에 있다는 이유로 그 앱의 모든 칸을 터미널로 다뤘습니다. 이제 그 목록도 다른 규칙과 같은 잣대를 씁니다. 목록에 있는 앱이라도 편집기가 커서 위치를 모른다고 할 때만 터미널입니다. Termux 의 터미널은 여전히 한글을 만들어지는 대로 보여 주고, 부가 키 입력칸은 다시 평범한 글자 칸입니다. 그대로인 것: Termux 자신의 화살표 버튼은 키보드에 알리지 않고 커서를 옮기므로, 그 직후의 지우기가 엉뚱한 글자를 지울 수 있습니다. 음절을 다시 그리는 동안 터미널 커서가 깜빡이는 것도 그대로입니다. - Sep 11, 2026 0.1.157
- Sep 10, 2026 0.1.164-legacy**Every layout answers to itself now.** With nothing chosen, a Dvorak or Colemak screen layout used to leave a plugged-in keyboard typing what its caps say, while every other language answered to its own layout. Choosing Colemak on the screen and finding QWERTY under your fingers is not a sane default. The exception had a true reason once — before v0.1.155 there were no Dvorak or Colemak tables, so the caps as printed was the only thing a physical keyboard could do — and it outlived it. The rule is now the same everywhere: **a screen layout that has a physical form answers to that form**, and one that has none — 천지인, a flick grid — answers to the layout its language does have. **This changes something if you had not touched the pairing:** with Dvorak or Colemak on the screen, a physical keyboard now follows the screen rather than the caps. If you want the caps as printed, say so on **Layout (portrait)** / **Layout (landscape)** — and if you had already chosen something, it is untouched. Two builds, one app: take **retekey-0.1.164.apk** unless your phone is older than Android 9, in which case take **retekey-0.1.164-legacy.apk** (Android 4.0+).
- Sep 10, 2026 0.1.163-legacy**A terminal is recognised by what it is, not by what it is called.** v0.1.162 fixed issue #7 by knowing Termux's name — which works in Termux and nowhere else. Every unit test was green; the phone was not. A terminal that reports a text field looks exactly like a login form with "show password" ticked, except in one thing: it does not know where its cursor is, because there is no buffer for one to be in. A text field always does. That signal names the *kind* of editor rather than the app, so Korean now works in terminals and SSH clients this keyboard has never heard of. Checked on a device this time, in both of Termux's input modes, through the real Android input framework: typing ㄱ, ㅏ, ㄴ gives ㄱ → 가 → 간, and backspace walks it back 간 → 가 → ㄱ. Two builds, one app: take **retekey-0.1.163.apk** unless your phone is older than Android 9, in which case take **retekey-0.1.163-legacy.apk** (Android 4.0+).
- Aug 31, 2026 0.1.150
- Aug 31, 2026 0.1.147
- Aug 31, 2026 0.1.150-legacyPersian guillemets, the real fix (issue #4, second report - thank you for the persistence, @xmha97). - The previous fix aimed the wrong way: the caps were never being mirrored - the **typed** marks were, by the bidi algorithm, once they sat in Persian text. A « typed as U+00BB renders flipped inside RTL text, so the cap and the text disagreed. - Key caps now **preview mirrored characters the way they will actually look in the layout's own text direction**: on Persian (and Arabic, Urdu, Hebrew) the caps are shaped in an RTL context - د's cap now shows « exactly as its character renders in Persian text - while French and other LTR layouts keep their LTR shape. - What the keys type is unchanged. Verified in the shipped screenshot; unit suites green on both flavors.
- Aug 30, 2026 0.1.149-legacyModifiers, three moves. - **The pad page's right-hand modifiers came alive**: RAlt, RCt and RSh are real latches - a tap arms for one key, a hold locks - and the state **survives switching layouts**, so you can arm Ctrl on the pad and finish the chord with an ordinary letter anywhere. RSh is a chording Shift for key events (Shift+arrow selection, Ctrl+Shift chords), distinct from the layout Shift. - **Modifier buttons for the action bar**: Ctrl, Meta, Alt, RCt, RAlt, RSh are available as bar actions (add them in action-bar settings). Same tap/hold split; a locked one keeps its accent on the bar until let up. - **The 12-key layouts' modifier column flipped**: 천지인, 나랏글, Arrows and Keypad now read Tab / Alt / Meta / Ctrl top to bottom - Ctrl nearest the thumb. All screenshots regenerated. Unit suites green on both flavors.
- Aug 29, 2026 0.1.138
- Aug 29, 2026 0.1.146-legacyTwo visibility improvements. - **Layouts grouped by language** in settings: the not-yet-enabled layouts now sit under small headings - ko (Korean), en (English), ru (Russian), and so on - so thirty-plus rows read as a dozen families. The enabled section keeps your own order, untouched. - **Three-letter abbreviations, bold capitals on the layout key**: every layout abbreviation grew to three letters (QWE, DVO, CMK, 2BS, CJI, NRG, FAS, RUS ...), and the layout key at the bottom right drops its ">" to show the next layout in bold capitals instead - easier to spot at a glance. Unit suites green on both flavors.
- Aug 27, 2026 0.1.133
- Aug 27, 2026 0.1.138-legacyNine layouts join at once: Russian, Ukrainian, Bulgarian (Phonetic), Macedonian, Serbian, Arabic, Urdu, Georgian and Armenian - each on its own standard positions, each with a fourth letter row where ten columns are not enough, and each typeable from a US physical keyboard on its language's own Windows layout. Thirty-two layouts in all.
- Aug 27, 2026 0.1.130
- Aug 26, 2026 0.1.132-legacyBackspace is reliable in remote-desktop apps now. Those apps show the keyboard a local dummy buffer, so deleting "surrounding text" only reached the remote machine while recently typed text still sat in that buffer - backspace worked right after typing and died otherwise. For Microsoft Remote Desktop and Chrome Remote Desktop, deletion now goes out as real backspace key events, which they always forward; typing and Korean composition keep their ordinary paths.
- Aug 26, 2026 0.1.120
- Aug 25, 2026 0.1.127-legacyBackspace works again in Google Docs, Samsung Notes and other editors that show the keyboard a proxy buffer whose cursor sits at position zero while the real document has text. The keyboard no longer decides from the reported cursor alone that there is nothing to delete: it always asks the editor itself, which is a harmless no-op at a genuine start of text. Reported with a physical keyboard on issue #3.
- Aug 23, 2026 0.1.120-legacyFrench AZERTY joins, in the 10/10/6 shape phones draw it: azertyuiop, qsdfghjklm, then shift w x c v b n backspace period enter. The fifteen accented letters are held under their vowels and c and picked along the hold strip; the period holds the comma and the guillemets.
- Aug 23, 2026 0.1.107
- Aug 22, 2026 0.1.113-legacy**The themed icon's eight keys have clear air between them sideways now.** In the source the caps sit 1.4 units apart — fine under the pale plate of the ordinary icon, but with no plate, at launcher size each row fused into a bar. On the themed layer only, each cap is narrowed by 1.6 units on both sides, so every gap is 4.6 units. Letters, rows and the ordinary icon are untouched.
- Aug 21, 2026 0.1.109-legacy**Automatic reserves the right space under the keyboard on every phone and navigation setting measured in [#1](https://github.com/rubidus-api/retekey_apk/issues/1).** The rule is one subtraction, and it is the reporter's: the system's furniture reaches `max(tappable, navigation)` pixels up from the physical bottom of the screen; the framework has already lifted the keyboard window some distance off that bottom; the band under the keys is the difference. On a phone whose window sits at the very bottom that is the whole furniture — what *Always* gave, and what worked. On a phone whose window is already placed above the bar it is little or nothing, which is what kept *Always* from being the default. Earlier versions measured the lift and then used it only as a cap on the navigation bar, which changed nothing on exactly the phones reporting the bug. The settings readout now shows the lift, so the three numbers on screen are the three terms of the rule.
- Aug 21, 2026 0.1.105
- Aug 20, 2026 0.1.107-legacy**Automatic no longer leaves the keyboard under the system's buttons in gesture navigation.** It was reserving the smaller of two insets, and in gesture navigation those two describe different things: the tappable-element inset is the gesture bar's own bounding box (42px on a Galaxy A56), while the navigation bar's inset is the whole zone the hide-keyboard and switch-keyboard buttons live in (135px). Taking the smaller lifted the keyboard clear of the gesture bar and left it under the buttons. The navigation bar is the furniture, so that is what Automatic follows now — still capped by how much of it is actually over the keyboard's own window, which is what keeps it at nothing on phones that already place the keyboard above the bar. Reported with measurements from two phones and several navigation settings in [#1](https://github.com/rubidus-api/retekey_apk/issues/1). Thank you.
- Aug 19, 2026 0.1.106-legacy**The action bar's slots can be dragged into order.** Each row in the list has a **≡** handle: press it, drag the row where you want it, drop it on another row. The **▲ ▼** arrows are still there for a precise nudge, and both go through the same rule, so a slot lands in the same place either way. **Default order** puts the shipped bar back, for a list that has been rearranged into something worse than it started as. No new library for it — the drag is the platform's own — and nothing changed in the keyboard itself; this is the settings screen.
- Aug 18, 2026 0.1.105-legacy**Automatic measures now instead of guessing.** The strip kept for the system's hide-keyboard and switch-keyboard buttons used to be decided from the window insets alone. Insets describe the *screen*, though, and the question is about the keyboard's own window: two phones can report the same navigation bar while one draws the keyboard underneath it — [#1](https://github.com/rubidus-api/retekey_apk/issues/1) — and the other has the keyboard placed above it already. The second was losing a strip of keyboard to furniture that was not over it. The keyboard now compares its own bottom edge against the top of the navigation bar and reserves only the part genuinely over it. Nothing over it, nothing reserved — whatever the bar's height says. **Settings → Space for the system's buttons** still has *Automatic*, *Always* and *Never*, and its readout now shows the measured overlap next to what the phone reports, so the two can be compared on a device where this still looks wrong.
- Aug 17, 2026 0.1.103-legacyThe little ring in the corner of **Ctrl, Meta, Alt, Tab and Shift** is gone. It filled in when the key latched, from a time when the key face said nothing about it. The face says it now — an armed key takes the soft accent, a held one is drawn inverted — so the ring was repeating it, in the corner every other key uses for what a hold reaches. The README pictures are taken from the drawing code again, so they show the keys as they are.
- Aug 14, 2026 0.1.94
- Aug 12, 2026 0.1.94-legacy**The key-click volume setting works now.** It was asking the platform to play its own keypress sound at a given volume, and plenty of devices — Samsung's among them — ignore that volume and use the system's touch-sound level instead, so the slider appeared to do nothing. The click is the keyboard's own sample now (twelve milliseconds, about a kilobyte), played through a SoundPool the keyboard owns, so the number you set is the volume you get. Zero still silences it. Reproducibility re-verified at this tag under JDK 21.
- Aug 11, 2026 0.1.93