Double-backspace on lock screen

[GoogleCodeExporter]

Cyanogenmod 11 snapshot M10

What steps will reproduce the problem?
1. Enable password lock screen
2. Lock phone
3. Try to unlock -- type in any characters (not necessarily real password)
4. Press backspace to erase 1 last character

What is the expected behavior?
1 character erased

What do you see instead?
2 characters erased

What version of Hacker's Keyboard are you using, for example "1.37"? (See
"Debug" section at the bottom of the app's Settings menu.)
1.37.1419

On what phone or tablet?
Samsung Galaxy S3 (SGH-T999L)

If applicable, does this affect the 4-row or 5-row layout, or both? Which
language(s)?
4-row; english or dvorak (same behavior)

Please provide any additional information below.

This did not happen with earlier versions of Cyanogenmod, so it's likely a new 
"feature" or an upgrade bug

Original issue reported on code.google.com by fry....@gmail.com on 3 Oct 2014 at 12:49

[GoogleCodeExporter]

1.37.1419 samsung galaxy s4 mini 9195, english dvorak czech all of them 
2characters erased on both 5 and 4 row layout.

Original comment by matej.se...@gmail.com on 20 Mar 2015 at 1:11

[GoogleCodeExporter]

I can't reproduce this, I would suspect it's a bug in the Cyanogen version 
you're using, sorry.

Original comment by klausw@google.com on 6 Apr 2015 at 10:38

• Changed state: Invalid

[GoogleCodeExporter]

Reopening, I dug around a bit further. The upstream LatinIME has some 
relevant-looking code, Hacker's Keyboard doesn't currently have this workaround 
in place.

Adding an equivalent check will be a bit annoying since it involves 
asynchronously looking up the target application in PackageManager, with some 
care needed to handle caching and memory leaks.

I'll see if an easier workaround is possible, i.e. special-casing the 
lockscreen for now.

https://android.googlesource.com/platform/packages/inputmethods/LatinIME/+/maste
r/java/src/com/android/inputmethod/latin/utils/TargetPackageInfoGetterTask.java

                if (inputTransaction.mSettingsValues.isBeforeJellyBean() ||
                        inputTransaction.mSettingsValues.mInputAttributes.isTypeNull()) {
                    // There are two possible reasons to send a key event: either the field has
                    // type TYPE_NULL, in which case the keyboard should send events, or we are
                    // running in backward compatibility mode. Before Jelly bean, the keyboard
                    // would simulate a hardware keyboard event on pressing enter or delete. This
                    // is bad for many reasons (there are race conditions with commits) but some
                    // applications are relying on this behavior so we continue to support it for
                    // older apps, so we retain this behavior if the app has target SDK < JellyBean.
                    sendDownUpKeyEvent(KeyEvent.KEYCODE_DEL);
                    if (mDeleteCount > Constants.DELETE_ACCELERATE_AT) {
                        sendDownUpKeyEvent(KeyEvent.KEYCODE_DEL);
                    }
                } else {

Original comment by Klaus.We...@gmail.com on 23 Apr 2015 at 5:36

• Changed state: Accepted

[GoogleCodeExporter]

I just wanted to mention for the sake of completeness that the topic @

https://groups.google.com/forum/m/#!topic/hackerskeyboard/O1jQR-Wkt40

has some additional details re: more bug reports.

Original comment by TPSam...@gmail.com on 24 Apr 2015 at 2:20

[GoogleCodeExporter]

Link collection for reference:

https://github.com/android/platform_frameworks_base/blob/a6ed1b9547dcd592031a415
739cc7e672c068f7c/core/java/android/view/KeyEvent.java#L60
 * As soft input methods can use multiple and inventive ways of inputting text,
 * there is no guarantee that any key press on a soft keyboard will generate a key
 * event: this is left to the IME's discretion, and in fact sending such events is
 * discouraged.  You should never rely on receiving KeyEvents for any key on a soft
 * input method.  In particular, the default software keyboard will never send any
 * key event to any application targetting Jelly Bean or later, and will only send
 * events for some presses of the delete and return keys to applications targetting
 * Ice Cream Sandwich or earlier.  Be aware that other software input methods may
 * never send key events regardless of the version.  Consider using editor actions
 * like {@link android.view.inputmethod.EditorInfo#IME_ACTION_DONE} if you need
 * specific interaction with the software keyboard, as it gives more visibility to
 * the user as to how your application will react to key presses.

https://android.googlesource.com/platform/packages/inputmethods/LatinIME/+/maste
r/java/src/com/android/inputmethod/latin/settings/SettingsValues.java
    public boolean isBeforeJellyBean() {
        final AppWorkaroundsUtils appWorkaroundUtils
                = mAppWorkarounds.get(null, TIMEOUT_TO_GET_TARGET_PACKAGE);
        return null == appWorkaroundUtils ? false : appWorkaroundUtils.isBeforeJellyBean();
    }

https://android.googlesource.com/platform/packages/inputmethods/LatinIME/+/maste
r/java/src/com/android/inputmethod/compat/AppWorkaroundsUtils.java
    public boolean isBeforeJellyBean() {
        if (null == mPackageInfo || null == mPackageInfo.applicationInfo) {
            return false;
        }
        return mPackageInfo.applicationInfo.targetSdkVersion < VERSION_CODES.JELLY_BEAN;
    }

https://android.googlesource.com/platform/packages/inputmethods/LatinIME/+/maste
r/java/src/com/android/inputmethod/latin/utils/TargetPackageInfoGetterTask.java

Original comment by Klaus.We...@gmail.com on 9 Jun 2015 at 6:18