Shift causes next number to be entered as shift+number about hackerskeyboard HOT 12 CLOSED

I've experienced this problem as well.  I didn't see the post until after I 
made one myself.  I'd just like to confirm that it occurs on my Motorola Droid 
X2, running 2.2.2 (Froyo).

I can reproduce it on my phone and am investigating - sorry about that, but 
it's unfortunately tricky since shift key handling is split among multiple 
classes with no clear separation of duties. (I may not have tackled this 
alternate keyboard if I'd known ahead of time that this would be so fragile...)

It's not happening in the emulator, so I'm guessing it's related to multitouch 
capable devices?

Issue 25 has been merged into this issue.

Progress, I think I found the issue, and it's arguably in the Android 
framework, not the keyboard app:

- InputMethodService's sendKeyChar() has odd special handling for digit keys, 
apparently using a built-in keymap to handle shifted characters at the OS 
level: 
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java
/android/inputmethodservice/InputMethodService.java#l1827

- for reasons I don't fully understand, the input handler is treating the 
sequence SHIFT down, SHIFT up as some kind of sticky shift state. Maybe a 
leftover from hardware keyboard handling?

Anyway, what got me on the right track was that the German keyboard produced a 
"&" on the 7 key due to this bug, while my keymap has a "/" in that location.

I've got a workaround which turned out to be fairly complicated, but I think 
I'm able to preserve the ability to use shifted arrow and other special keys 
without triggering the framework bug. Release soon, once I've cleaned up the 
debugging code I added while tracking this down.

Fantastic, Klaus. Thanks for the rapid response. I've got a rooted device, so I 
can test any beta apk's for you.

This issue was closed by revision a1e772c1aa38.

Please try v1.14rc3 (or later) which should fix it: 
http://code.google.com/p/hackerskeyboard/downloads/list

BTW, rooting should not be necessary for trying the prereleases, you just need 
to permit non-Market installs in your application settings. AFAIK only some 
AT&T phones have this locked down and require rooting (or "adb install" via 
USB?) as a workaround.

Fantastic, again! That solved the problem.

I have not attempted this fix yet but I appreciate the quick turn-around and 
excellent communication.  I'm looking forward to assisting with testing in the 
future :)

When can we expect this update to be on the market?

It's very easy to install from the Downloads link, Kaishi. Just enable 
non-market installs. It worked for me immediately.

Bulk update - changing "Fixed" to "Verified" for old bugs.

(Background: I'm changing the "Fixed" status to be considered open, the next 
steps in the lifecycle will be the closed states "FixInTest" and "Verified". 
This lets me mark issues as "Fixed" in commit messages without hiding them from 
the issue tracker.)

Bulk update - changing "Fixed" to "Verified" for old bugs.