Why users quit at the TV pairing code screen: a 6-character code and a Korean keyboard
After fixing a pairing bug in our TV remote app, the share of users who cancelled on the code entry screen went from 9% to 19%. How the GA4 failure reasons were read, how one input field turned out to open the Korean keyboard, and what was changed.
A fix that raised a different number
We run remote control apps that control Android TV set-top boxes over Wi-Fi. On the first connection the TV shows a 6-character code, and the user types it on the phone to pair.
Version 1.2.17 (October 2) fixed a bug that treated TVs that still needed pairing as a plain connection failure. The effect showed right away. In GA4, among users who tried to connect, the share ending in connect_error fell from 38% to 7% in the U+TV app (7 days before vs 3 days after release, users who had not updated yet included).
But in the same table, code_cancel — users who cancelled on the code entry screen — went from 9% to 19%.
Reading the numbers first
The two numbers are linked. People who used to fail before ever reaching the code screen now reach it, because the bug is fixed. connect_error dropped by 31 points and code_cancel rose by 10, so roughly one in three of the people newly reaching the code screen gave up there.
So the real question was: why do people get stuck on the code screen?
The code is 6 hexadecimal characters
The app asks for a code length of 6 when pairing. On the device we verified (a Chromecast), the code was hexadecimal, like 4A2F1C. Each position is a digit with probability 10/16, so all six are digits with probability (10/16)^6 ≈ 6%. About 94% of codes contain at least one letter A–F.
The input field looked like this:
<EditText
android:inputType="textCapCharacters|textNoSuggestions" />
A plain text field. In that case the keyboard opens in the language the user last used. We had already been told about this on October 2 in another app (our new TV remote app): "the keyboard on the 6-digit screen opens in Korean". Most Korean users last typed in Korean, so pressing the key for the A shown on the TV puts ㅁ in the field. If they can't find the language switch key, they can't finish the code.
The new app was fixed that day, but the same screen in our four existing remote apps had not been updated.
Three changes
1. Open the English keyboard
<EditText
android:inputType="textVisiblePassword|textCapCharacters|textNoSuggestions" />
Keyboards often open an English layout for password-type fields. With visiblePassword the characters are not hidden. We have not yet confirmed on real devices that every keyboard does this.
2. If Korean still comes in, read it as the English key in the same position
On the standard Korean (2-set) layout, ㅁ sits on the A key and ㅊ on the C key. So when Korean characters arrive, we convert them to the English key at the same position, show that in the boxes and submit it. Korean letters combine into syllables (C + B = 츄), so syllables are first split into their initial, medial and final parts.
// 츄 → ㅊ + ㅠ → c + b
int v = c - 0xAC00;
int cho = v / (21 * 28), jung = (v % (21 * 28)) / 28, jong = v % 28;
This does not match other Korean layouts such as Cheonjiin, but then the user simply sees "the code does not match" and types again — no worse than before.
3. A "No code on the TV · Show the code again" button
Sometimes the code is not visible at all — if the TV is on a different input, the set-top screen with the code is not shown. Previously the only option was to cancel. Now one button opens a new pairing session and shows a fresh code.
What we will measure next
Along with this fix, the app now records how far the user got when cancelling:
| Value | Meaning |
|---|---|
empty |
Cancelled without typing anything — couldn't see the code, or didn't know what to do |
partial |
Typed a few characters, then cancelled — likely stuck on input |
full |
Typed all 6, then cancelled |
after_wrong |
Cancelled after a "wrong code" message |
again |
Asked to show the code again |
Version 1.2.18 was submitted on October 6. In a week we will split the cancellations into "keyboard problem" vs "code not visible" with these values and follow up.
Summary
- When fixing a bug makes a different failure reason go up, first check whether people simply moved one step further in the same funnel. Looking at one number alone reads as "it got worse".
- Don't use a plain
textfield for letter-and-digit codes. For Korean users it fails from the first character. - If several apps share the same screen, port an input fix to all of them right away. This time it was four days late.
The app in this post is U+TV Remote (Google Play).