sspanak / tt9

A T9 keyboard for Android devices with a hardware keypad.
Apache License 2.0
244 stars 41 forks source link

Number keys are typed twice in dialer on LG X100S #300

Closed felipecrs closed 5 months ago

felipecrs commented 1 year ago

Anyway, let's hold on with that. In #241, we have discussed a completely new implementation of the numeric modes. I am hoping it will solve all undesired side effects once and for all. Let's see how it goes and if you still have problems after it, I suggest you open a new issue specifically for the LG phone, where we can keep discussing the matter.

I can't believe the most difficult part of making an Android keyboard is making it type numbers... :exploding_head:

Originally posted by @sspanak in https://github.com/sspanak/tt9/issues/261#issuecomment-1621124468

felipecrs commented 1 year ago

Out of curiosity, I tested with v23.0 today and the issue remains.

sspanak commented 1 year ago

v23.0 in mostly about new languages and improved typing experience in Predictive mode.

However, v23.7 includes many bugfixes, including the new Numeric mode. Please, try it out and let me know if it fixes the problem.

felipecrs commented 1 year ago

Awesome, will try it out later today. Thanks!

felipecrs commented 1 year ago

Unfortunately the exact same issue happens with 23.7. :(

sspanak commented 1 year ago

So sad... OK, I'll review what has changed since version 20.0 and try to figure out what could be causing the problem on LG.

mehanix commented 1 year ago

Hi, just came across this, as a new owner of the lg x100s.

This is merely anectodal but I have observed that if, after the first time you press a numeric key in the dialer and you get a double digit(let's say 00), if you delete the first 0 and try to type the rest of the number it will work normally and no longer duplicate. It is quite odd but it works as a workaround for now, for me at least.

Maybe this will help you debug the issue? I could also try to look at it and see if I can figure out what's wrong (but I am a bit short on time lately and also not familiar with Android development at all unfortunately)

sspanak commented 1 year ago

Maybe this will help you debug the issue?

Not really, unfortunatelly. I have some more questions, though.

  1. Let's say it started repeating "0". Does it keep typing "00" on every subsequent 0-key press?
  2. Does the number of repeated zeros increase, if you keep pressing 0-key?
  3. If you press another number key, say 3, does it repeat anything, for example: "33", "03", "30"?
  4. Does typing a "*" (a star) after the first repeat change anything?
    1. Do you see double stars?
    2. Does pressing 0-key cause double zeros again.
    3. Does pressing another key cause double numbers?
  5. What happens if you hold another number key, then press 0-key. Do you still get double zeros?
mehanix commented 1 year ago

Maybe this will help you debug the issue?

Not really, unfortunatelly. I have some more questions, though.

1. Let's say it started repeating "0". Does it keep typing "00" on every subsequent 0-key press?

Yes, until I decide to delete one. From that point onwards, if i press '0' again, only one key press is registered.

2. Does the number of repeated zeros increase, if you keep pressing 0-key?

No, it's always a pair of 2 digits (happens on every number not just 0)

3. If you press another number key, say 3, does it repeat anything, for example: "33", "03", "30"?

I'll just get '33' until i decide to delete one of them. From that point onwards numbers are registered correctly.

For instance, for one '0' press and one '3' press I'll get : 0033. If i press "clear", output is now 003. If I press 0, 3, again, output is now: 00303.

I also noticed that the fixed behavior seems to persist quite a while after I delete a character (even if I kill the dialer process and start it again). Restarting the phone leads to digit duplication again.

4. Does typing a "*" (a star) after the first repeat change anything?

no

  1. Do you see double stars? yes
  2. Does pressing 0-key cause double zeros again. yes
  3. Does pressing another key cause double numbers? yes
    1. What happens if you hold another number key, then press 0-key. Do you still get double zeros? ohh this is interesting:
      • i hold another number key (let's say 9) - one 9 appears
      • press 0, two zeroes appear
      • release 9 key, another 9 appears. output: 9009

Sounds like some sort of event mishap (button press vs tap and release). With how easy it is fixed though (just remove one of the duplicates and it's fixed until phone restart) I feel it is not a major bug though.

sspanak commented 1 year ago

Alright, so the problem is numbers are being typed both on keyDown and keyUp events.

Some more questions, again assuming repeating occurs again:

  1. When you hold a number key, does the number appear while you are holding the key or after you release it?
  2. After you "fix" the problem with Backspace, when do the numbers appear when - when you press or when you release the respective key? It may be a bit tricky to find this out, but you could try releasing the key slightly slower than normal, so you can notice the exact moment when the number appears.

I feel it is not a major bug though.

Yes, but it is so persistent, I am intrgued what is wrong now. :nerd_face:

mehanix commented 1 year ago
  1. While I'm holding, I get the first 0 to appear (keyDown). second 0 appears on keyUp
  2. it appears when i press the key rather than releasing (so on keyDown).keyUp no longer makes a 0 appear.

Seems that doing a backspace somehow changes the way keyUp is interpreted? Really odd bug nonetheless.

LE: I did some more digging and just realised that there's a actually a difference between closing the dialer app from the Android .. square button menu (not familiar with the terms), and actually force stopping the process. If I force-stop com.android.phone and retry to type in a number, digit duplication happens again.

sspanak commented 1 year ago

Seems that doing a backspace somehow changes the way keyUp is interpreted? Really odd bug nonetheless.

It seems the case, yes. Odd, indeed.

Here is my theory (for when I get back to the issue and I had already forgotten it):

TT9 types characters only when keys are released, but Backspace and the other hotkeys are handled upon key press. When interacting with a Dialer app, TT9 must completely ignore all keys and let the system handle them. This is controlled by if (shouldBeOff()) {... both in KeyPadHandler.onKeyDown() and KeyPadHandler.onKeyUp(). However, a) Backspace is obviously handled, and b) Digits appearing both on key press and release most likely means one comes from the system handler, the other one comes from TT9.

All this means that, for some reason, shouldBeOff() incorrectly returns false in the Dialer, until Backspace is pressed.

Moreover there is a chance that TT9 crashes when Backspace is pressed, causing it to no longer handle anything, letting the system type digits. This would seemingly fix the problem. I am suggesting this, because there was a report in #367, that mInputMode is NULL sometimes, causing a crash exactly when checking shouldBeOff(); and because the order of initial validations in onBackspace() and shouldBeOff() is different and shouldBeOff() may not crash in the specific case of LG X100S.

It is just a theory, I may be completely wrong, but it is a clue.

did some more digging and just realised that there's a actually a difference between closing the dialer app from the Android .. square button menu (not familiar with the terms), and actually force stopping the process. If I force-stop com.android.phone and retry to type in a number, digit duplication happens again.

Right, the button just puts the app in the background, it does not close or kill it.

sspanak commented 8 months ago

@felipecrs , @mehanix , please try the new v27.0 and let me know if it fixes the problem for you.

I have fixed an occasional crash that caused weird side-effects, including characters incorrectly appearing on screen.

mehanix commented 8 months ago

thanks a bunch, ill get back to you on this :)

mehanix commented 8 months ago

nope, still happens on my end :( exactly the same behavior as before.

v27 seems much faster though and i would be really happy if the disappearing letters bug actually is resolved - i'll report back on it after a couple of days of usage, it does seem much snappier.

i'd like to also note that after the update i had to manually reload the dictionaries - prediction completely stopped until i did that. if this is expected behavior and i didn't read the instructions properly, my bad.

sspanak commented 8 months ago

nope, still happens on my end :( exactly the same behavior as before.

My theory is completely wrong then and I am out of ideas. I can't fix this remotely. Someone with a LG X100S has to either debug it or send me the phone. :slightly_smiling_face:

v27 seems much faster though and i would be really happy if the disappearing letters bug actually is resolved... i'd like to also note that after the update i had to manually reload the dictionaries

Yes, I have completely restructured the database to be faster, but the downside is you start with blank tables in v27.0. I am thinking it may be a good idea to enable automatic dictionary loading. Other users have already requested it.

mehanix commented 8 months ago

I could try my hand at it once I finish some pressing work (finishing my master's this year so lots of things going on). I'll let you know if someone else doesn't take it up until then. I am not really familiar with android dev though so it might take me a while. Thanks again!!

Docbroke commented 8 months ago

Hi, I am having similar issue with cat s22 flip, android 11 go, build v30 (latest available). To shortly describe the issue.

  1. I noticed the issue of number keys typed twice in paytm app, while entering amount for payment. Using different keyboard or just keeping some onscreen keyboard, while using physical number buttons solves the issue.
  2. the issue is there with all number keys in paytm app, not only first pressed number key.
  3. After reading this issue I tried long pressing and realized that number appears on screen both on key-press and key-release.
  4. In default dialer there is no double typing, but I also tried in Koler (another dialer from github) and it has exactly same issue as described in this thread, where number which is pressed first is type twice but after that there is no double typing for other number keys.
sspanak commented 8 months ago

I don't have a CAT or an LG phone and I don't have an account in Paytm, but Koler is a useful suggestion. I tried it out and I am definitely seeing issues with. For me, the problems start, if I use the phone keypad and Koler's keypad together. And after I hit Backspace, all input becomes completely messed up. So it's kind of the other way around for me, but it's a clue. I'll investigate more next week.

I could try my hand at it once I finish some pressing work (finishing my master's this year so lots of things going on). I'll let you know if someone else doesn't take it up until then. I am not really familiar with android dev though so it might take me a while. Thanks again!!

If I can't figure it out after debugging Koler, it would be much appreciated. You don't need to learn Android programming in general. You will just have to install Android Studio. I'll tell you what file and what function needs to be debugged. In the end, in this kind of languages, all programming is just if, else and for, and calling some API/library that doesn't work properly. :slightly_smiling_face:

P.S. I am leaving a link to Koler here. I don't want to search for it again.

Docbroke commented 8 months ago

When keys from koler keyboard is pressed, koler removes numbers pressed using physical keyboard. I think this is probably koler specific issue and not related with tt9. It happens on my device too.

sspanak commented 7 months ago

Revisiting the problem, I have added a new debugging option, which will hopefully lead to resolving it.

If anyone is willing to help debugging, please do the following:

  1. Make sure to update to v29.0.
  2. Open the TT9 Settings.
  3. Scroll down to the version information and click it. The Debug Options screen will appear.
  4. Look for the "Keypad Handling Mode" option. Change it to "return false" or "call super", then try dialing a number again. One of these modes should theoretically result in correct behavior.
  5. Once you are done testing, do not forget to change the Handling Mode back to "normal", otherwise it will not be possible to type anything but numbers.
felipecrs commented 6 months ago

Super thanks @sspanak, and sorry for taking this long to reply.

I tested and both options worked:

https://github.com/sspanak/tt9/assets/29582865/e0cf51f5-99d0-4294-beaf-eb545e336890

sspanak commented 6 months ago

Excellent! Now I know what is wrong. It's just that the dialer is not recognized correctly. I'll need some more information and I'll include the necessary debugging tools in the next version. Stay tuned.

sspanak commented 6 months ago

@felipecrs, @mehanix, @Docbroke, now that v30.0 is out, may I ask you to do the following after installing it:

First, I need the phone make and model strings.

  1. Go to TT9 Settings
  2. Scroll to the version number and click on it to open the Debug Options.
  3. At the top, you'll see "Device Info". You can click it to copy the two strings. I need them, including the quotes.

The second piece of information is the dialer package name.

  1. On the Debug Options screen, find "Log Level" and change it to "info".
  2. Go to the dialer and type one number.
  3. Quickly go back to the Debug Screen and change the "Log Level" to "error", to prevent flooding the log files with unnecessary information and taking up space on the phone.
  4. In the logs list you will see a lot of messages like this:
    ===> Start Up; packageName: com.android.chrome inputType: 0 actionId: 0 imeOptions: 301989888...
    ===> Start Up; packageName: com.google.android.apps.nexuslauncher inputType: 0 actionId: 0 imeOptions...
    ===> Start Up; packageName: com.google.android.googlequicksearchbox inputType: 524289 actionId: 0 imeOptions: 234881027...

    I need the one that says "something-something-dialer". It may be "com.android.dialer" or something similar. You can click the logs to copy them, then paste them in a message or the notes app (if you have one) to take them out of the phone more easily and post them here. It's OK to copy-paste everything, I'll find what I need. It's also OK to make a screenshot of the dialer package name, it doesn't matter.

With this information, I should be able to fix the problem.

felipecrs commented 6 months ago

"LGE" "LGM-X100S"

04-18 19:36:04.046  2199  2199 I tt9/KeyPadHandler: ===> Start Up; packageName: io.github.sspanak.tt9 inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

04-18 19:36:07.023  2199  2199 I tt9/KeyPadHandler: ===> Start Up; packageName: com.lge.easyhome inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

04-18 19:36:08.465  2199  2199 I tt9/KeyPadHandler: ===> Start Up; packageName: com.android.contacts inputType: 3 actionId: 0 imeOptions: 1140850694 privateImeOptions: null extras: null

04-18 19:36:08.466  2199  2199 W tt9/validateMode: Invalid input mode: 0 Enforcing: 2

04-18 19:36:12.450  2199  2199 I tt9/KeyPadHandler: ===> Start Up; packageName: com.android.systemui inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

04-18 19:36:12.910  2199  2199 I tt9/KeyPadHandler: ===> Start Up; packageName: io.github.sspanak.tt9 inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

04-18 19:36:13.889  2199  2199 I tt9/KeyPadHandler: ===> Start Up; packageName: io.github.sspanak.tt9 inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

it should be the com.android.contacts one, because that's the name it shows when I open the App Info screen for the dialer.

felipecrs commented 6 months ago

Btw, I wonder how come it works when using tt9 v20. lol

felipecrs commented 6 months ago

Oh, this is interesting:

04-18 19:36:08.466  2199  2199 W tt9/validateMode: Invalid input mode: 0 Enforcing: 2

Perhaps v21+ dropped support for such "mode: 0"?

felipecrs commented 6 months ago

Perhaps something related to this:

https://github.com/sspanak/tt9/compare/v20.0...v21.0#diff-2e2aefe622ad448cccc566627ec294fd113a0af8b7ea9dd86034e81354bd48ecL19

https://github.com/sspanak/tt9/compare/v20.0...v21.0#diff-2e2aefe622ad448cccc566627ec294fd113a0af8b7ea9dd86034e81354bd48ecL301-L303

sspanak commented 6 months ago

Sort of, you almost got it right. 🙂

Currently, there are two numeric modes, called "123" and "Passthrough". The first one is the one you can select manually and is labeled [ 123 ] in the status bar. It works by generating strings consisting of numbers and sending them to the connected application. This is the recommended way of typing according to the Android development guide. And this seems to work correctly on all phones so far.

In the earlier versions, I don't remember which ones correctly, but I guess < 20, the current "Passthrough" mode was then "123". This mode just passes the key press events and codes from the Android core (probably, the keyboard driver) to the application. This is also fine for the most part, but it turned out some applications don't know what to do with key codes and need strings. That's the reason I changed the operation mode.

There are other applications, dialers, and calculators, as per the reports so far, that actually understand both. They are even able to read the key codes before the keyboard (TT9). And since the keyboard and the application are racing together, sometimes they both pick up the key press and generate some number. This is what causes the double numbers. And since in the earlier versions, there was no string generation, there was no way for the problem to happen.

I am well aware of all this since a long time ago, but what I didn't know is, that dialers have different package names. Usually, it is "com.android.dialer". I am detecting this one and switching to "Passthrough", making TT9 invisible and allowing only the dialer to handle the input. But, obviously, on the LG X100S, it isn't "com.android.dialer", it is "com.android.contacts".

Now, "com.android.contacts" could lead to another problem. This is also the name of the phonebook application. Switching the numeric mode when you are editing or adding a new contact may not be desirable.

Could you please also go to the phonebook, select the phone fields, and paste the "Start Up" logs for them, too? I'd like to exclude them from the dialer hack.

Just to make sure everything is clear, I need the "Start Up" log for the field from the screenshot: Screenshot_20240419-101138

sspanak commented 5 months ago

I didn't get that extra information, but I think I've managed the to fix the problem. Everyone, you are welcome to install and use v31.0. If the dialer works fine, please let me know, so I can finally close this issue.

felipecrs commented 5 months ago

@sspanak first I would like to say I am super grateful for all your effort into solving this issue. Thank you!

Second, I want to apologize for taking so long to reply you. The problem is that this is my father's phone and I don't always have the opportunity to tinker with it.

Lastly, I'm afraid to say this issue was not resolved yet. :(

https://github.com/sspanak/tt9/assets/29582865/924230f4-018b-4019-b06b-7a78a57dbd8f

However, I now captured the logs you wanted:

05-17 18:28:55.686  9218  9218 I tt9/KeyPadHandler: ===> Start Up; packageName: com.lge.easyhome inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

05-17 18:28:56.519  9218  9218 I tt9/KeyPadHandler: ===> Start Up; packageName: com.lge.easyhome inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

05-17 18:28:58.111  9218  9218 I tt9/KeyPadHandler: ===> Start Up; packageName: com.android.contacts inputType: 3 actionId: 0 imeOptions: 1073741830 privateImeOptions: null extras: null

05-17 18:28:58.113  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:28:58.165  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:28:59.650  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:28:59.654  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:28:59.656  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:28:59.683  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:28:59.700  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:02.320  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:09.496  9218  9218 I tt9/KeyPadHandler: ===> Start Up; packageName: com.android.contacts inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

05-17 18:29:12.542  9218  9218 I tt9/KeyPadHandler: ===> Start Up; packageName: com.android.contacts inputType: 532577 actionId: 0 imeOptions: 134217733 privateImeOptions: com.lge.android.editmode.noEmoji extras: null

05-17 18:29:14.863  9218  9218 I tt9/KeyPadHandler: ===> Start Up; packageName: com.android.contacts inputType: 3 actionId: 0 imeOptions: 67108870 privateImeOptions: com.lge.android.editmode.noEmoji extras: null

05-17 18:29:14.865  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:14.902  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:14.906  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:14.908  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:14.910  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:14.955  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:14.985  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:20.273  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:21.055  9218  9218 W tt9/validateMode: Invalid input mode: 1 Enforcing: 2

05-17 18:29:26.553  9218  9218 I tt9/KeyPadHandler: ===> Start Up; packageName: com.android.systemui inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

05-17 18:29:26.936  9218  9218 I tt9/KeyPadHandler: ===> Start Up; packageName: io.github.sspanak.tt9 inputType: 0 actionId: 0 imeOptions: 0 privateImeOptions: null extras: null

Please note te way I generated these logs:

  1. Enabled INFO logs
  2. Home -> Dialer
  3. Type number 2 once, then typed 2 again (to reproduce the issue)
  4. Clicked on create new contact
  5. Selected the number field, and typed number 3 twice (everything is working ok here by the way).
sspanak commented 5 months ago

I would like to say I am super grateful for all your effort into solving this issue. Thank you!

@felipecrs, you are welcome! I must also thank you for your effort in testing. I can not really do this on my own. Hopefully, we can solve the problem in the end.

Second, I want to apologize for taking so long to reply you. The problem is that this is my father's phone and I don't always have the opportunity to tinker with it.

All good, I understand.

However, I now captured the logs you wanted...

I see. It looks like the dialer field changes its flags for some reason. In other words, the imeOptions were different in the log you sent previously. It is strange, but it is not the first time I've seen it. The same happens on Sonim XP3800, in the contact search field.

Anyway, here is v31.19 with less strict detection rules. If it still doesn't work, I can relax them even more. I am doing small steps, because I don't want to cause side effects in other unrelated input fields.

felipecrs commented 5 months ago

Awesome! It's now working flawlessly:

https://github.com/sspanak/tt9/assets/29582865/d1a4aed7-ae04-4d14-a3f1-77dd29edd3c8

sspanak commented 5 months ago

Awesome indeed! After almost a year, I can finally close this bug.