“Way to GI, Android!” A Critical Look at the Standard Android Keyboard

The Lollipop release of Android has really taken the operating system to new heights. Vast improvements to performance, experience and design have made it a very worthy competitor to iOS. However, as an extensive user of both platforms, I believe that the auto-correction engine of the default Android keyboard remains far weaker than its iOS counterpart. It is hard to quantitatively measure how well auto-correction is performing between the platforms, but I will give some compelling examples below of how Android auto-correction is falling short.

For these examples, the exact same letters were carefully typed into both an iOS 8 device and a Nexus-branded Android 5.0 device. Of course, the keyboards may use precise positioning and timing of touches to further refine its correction. However, all of the corrections (or failures to correct) were reliably reproduced in repeated tests. The keyboards were configured to default settings, but personalized auto-corrections and contact name auto-corrections were turned off.

Four classes of problems were discovered during testing, listed here in descending order or severity.

Weakness 1 — Obscure Acronym Corrections

This is the most painful auto-correction failure, because it comes up so regularly and is always ludicrous:

[iOS] i will gi with you → I will go with you

[Android] i will gi with you → I will GI with you

Here, the Android keyboard sincerely believes that I intended to say “I will general issue with you.” Here is another:

[iOS] a long time afo → A long time ago

[Android] a long time afo → A long time AFO

The acronym “AFO” is so obscure that it’s not clear to what it could refer, perhaps Air Force One or Anime Festival Orlando?

Weakness 2 — Poor Context Sensitivity

The iOS and Android keyboards make context-sensitive corrections driven by grammar considerations. However, Android makes some simple blunders that should be obvious from context:

[iOS] i have yo go → I have to go

[Android] i have yo go → I have yo go

[iOS] i know why its wrong → I know why it’s wrong

[Android] i know why its wrong → I know why its wrong

It seems that the Android engine is placing too much weight on what was actually typed by the user, even if it makes no sense.

Weakness 3 — Poor recognition of Spacebar Misses

Android does recognize when letters such as c, v and b are erroneously typed instead of the spacebar, but it does not do as good a job at it as iOS, especially for shorter words:

[iOS] bevpolite → Be polite

[Android] bevpolite → Bevpolite

[iOS] ibam going home → I am going home

[Android] ibam going home → Ibam going home

Weakness 4 — Failure to Aggressively Correct

This seems to be more of a thresholding issue than a core weakness of the auto-correction engine. In the presence of two or more erroneous letters in a word, Android will often determine and offer up the correct word as an auto-correct option, but will not automatically make the correction, forcing the user to either monitor the corrections as they are offered, or return to the word at a later time to make the fix. Meanwhile, iOS is far less satisfied to leave apparent gibberish in place:

[iOS] i fprhed it → I forged it

[Android] I fprhed it → I fprhed it

[iOS] a great brsim → A great brain

[Android] a great brsim → A great brsim

While both of these words contain two errors, they are each adjacent to the nearby correct letter. Android is aware that “forged” and “brain” are the most likely correction candidates, but does not take action.

However, this is only the behavior at the default settings. It is possible to configure the aggressiveness Android keyboard, although it is buried:

Settings > Language & input > Google Keyboard > Text Correction > Auto-correction > Very aggressive

This setting substantially mitigates the issue, and is highly recommended. However, users cannot be expected to manually configure their keyboard.

Recommendations

It is surprising that Google isn’t ahead of the competition on touch keyboard auto-correction as they lead the way on related machine learning problems, such as translation and dictation. The keyboard team should begin by typing on iOS for a few weeks, the better to know their enemy. In parallel, they should develop an analytical framework for measuring how well they are doing. If it already exists, then it should be improved so that it is driven by real, everyday use. An opt-in, anonymized tracker of user keyboard activity could gather valuable statistics on how often a user needs to manually resolve failed corrections. Undoubtedly, issues such as “yo” and “gi” would become glaring under such scrutiny.