EEltaCrew
Home › Blog

Why users quit at the TV pairing code screen: a 6-character code and a Korean keyboard

Published 2026-10-06Measured 2026-10-05About 4 min readelta · EltaCrew

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

The app in this post is U+TV Remote (Google Play).

AndroidEditTextKeyboardGA4TV remote

Related

Why our lottery ticket QR scanner showed zero successes: a path you don't log looks like a failureIn our lottery app's weekly report, 19 people had opened the QR screen and GA4 showed zero successful scans. The scanner wasn't broken. The path that real ticket QR codes took had no logging at all. How we found the measurement gap, what four similar apps do, why we switched to the bundled scanning engine, and the numbers one week after the fix.Tapping the logo in the map's corner crashed the app: Naver Map SDK and the AppCompat themeFour "You need to use a Theme.AppCompat theme" crashes showed up in Crashlytics for our lottery store map app. They came not from users but from the Play pre-launch report's test robot tapping the NAVER logo in the bottom-left corner of the map. The cause, a fix that wraps only the map instead of changing the whole app theme, and a second problem that appeared in dark mode.Requesting ads before the SDK finishes initializing: why the same crash came back three times after we added a guardAfter we first fixed the "MobileAds.initialize must be called" crash in our live apps, the same crash came back three more times in different shapes. We had a guard that waited for initialization to finish, but a flag set at the start, a flag set on consent alone, and new ad slots that skipped the guard all left gaps. The cause of each case and the results of checking all 23 apps.