tt9
tt9 copied to clipboard
Number keys are typed twice in dialer on LG X100S
- This issue is a continuation from https://github.com/sspanak/tt9/issues/261#issuecomment-1621124468:
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
Out of curiosity, I tested with v23.0 today and the issue remains.
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.
Awesome, will try it out later today. Thanks!
Unfortunately the exact same issue happens with 23.7. :(
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.
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)
Maybe this will help you debug the issue?
Not really, unfortunatelly. I have some more questions, though.
- Let's say it started repeating "0". Does it keep typing "00" on every subsequent 0-key press?
- Does the number of repeated zeros increase, if you keep pressing 0-key?
- If you press another number key, say 3, does it repeat anything, for example: "33", "03", "30"?
- Does typing a "*" (a star) after the first repeat change anything?
- Do you see double stars?
- Does pressing 0-key cause double zeros again.
- Does pressing another key cause double numbers?
- What happens if you hold another number key, then press 0-key. Do you still get double zeros?
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
5. 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.
Alright, so the problem is numbers are being typed both on keyDown
and keyUp
events.
Some more questions, again assuming repeating occurs again:
- When you hold a number key, does the number appear while you are holding the key or after you release it?
- 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:
- While I'm holding, I get the first 0 to appear (
keyDown
). second 0 appears onkeyUp
- 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.
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.
@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.
thanks a bunch, ill get back to you on this :)
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.
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.
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!!
Hi, I am having similar issue with cat s22 flip, android 11 go, build v30 (latest available). To shortly describe the issue.
- 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.
- the issue is there with all number keys in paytm app, not only first pressed number key.
- After reading this issue I tried long pressing and realized that number appears on screen both on key-press and key-release.
- 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.
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.
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.
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:
- Make sure to update to v29.0.
- Open the TT9 Settings.
- Scroll down to the version information and click it. The Debug Options screen will appear.
- 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.
- 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.
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
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.
@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.
- Go to TT9 Settings
- Scroll to the version number and click on it to open the Debug Options.
- 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.
- On the Debug Options screen, find "Log Level" and change it to "info".
- Go to the dialer and type one number.
- 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.
- 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.
"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.
Btw, I wonder how come it works when using tt9 v20. lol
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"?
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"?
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
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
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:
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:
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.
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.
@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:
- Enabled INFO logs
- Home -> Dialer
- Type number 2 once, then typed 2 again (to reproduce the issue)
- Clicked on create new contact
- Selected the number field, and typed number 3 twice (everything is working ok here by the way).