I noticed this as well. It seems to depend on which Android version is used. I have a few Android 5 and 6 devices (Nexus 10, Nexus 7 2013, Nvidia SHIELD tablet), and they all still show the correct full German layout after the update. Only my Nexus 9 and Nexus 5x (running Android 7.0) have the issue.
Right, should have added:
I have a Nexus 6 with Android 7.0
Here the same, on Nexus 5 (6.0.1 (M4B30Z, Dec 2016)) and Nexus 9 (7.1.1 (NMF26F, Dec 2016))
But my german layout (nexus5) looks different:

So it's also on Android 6.
Hi,
my keybord looks like the second screenshot in landscape. But I think the letters in the new version are much too heavy/fat/bold. The keybord takes more then half of screens height, so often it's impossible to see the input fields while writing.
It would be nice, when there would be a possibility to "zoom" the keyboard (or something like this)
Btw. I'm using a ASUS zen-pad 8.0 with Android 5.0.2
Regards
Michael
I am using _Cyanogen Mod_: cm-14.1-20161210-NIGHTLY device=bacon (_OnePlus One_) with Android 7.1.1 and _Hackerâs Keyboard_ v1.39.1
The 5-row layout shows normal English layout but the very same wrong German layout as in the first screen shot (x v l c w z âŠ)âin portrait as well as in landscape mode.
The 4-row layout is correct.
What puzzles me is the fact that v1.39.1 has been committed on 2016-10-22 and according to the comment on _GooglePlay: Hackerâs Keyboard_ it has been released there on 2016-12-08 (that has taken quite some time).
Despite the error: thanks a lot for your work!!!!
Regards,
Kalten
Same issue on cm 14 falcon android 7.1.
gingerbread mode has wrong chars over qwertz (153)-6).
5 rows mode is a disaster. No k char but double z and many irritations.
I forgit to report that both play store and f-droid repositories are concerned
I'll try to get a fix out today. Apparently Android's inheritance rules for localized resources are very weird, the German layout picks up settings from the newly added Neo2 layout with locale de_rNE even though that locale isn't active. It used to keep the global defaults in that case which seems much more logical. Sorry about the confusion.
@Kalten666 Part of the reason for the delayed Play Store release was to catch issues and regressions while it was in alpha test, but that obviously didn't help in this case...
FYI @stoertie, there's a setting to adjust the keyboard height as a percentage of screen size, and a separate scaling factor for the 5th row in case you want a smaller number row.
Hi Klaus,
thanks a lot vor the information... I.just found the setting a few hours ago. Sometimes the "one-eyed" is king among the blinds. :-) Noe it looks perfect at my tablet.
regards
Michael
I've pushed version 1.39.3 to the Play Store which should fix it. Let me know if you still see differences from the earlier version.
Also available here: https://github.com/klausw/hackerskeyboard/releases/tag/1.39.3
https://github.com/klausw/hackerskeyboard/commit/0394abcfe55579a94e7752a536aa41f1e8ef47eb
https://github.com/klausw/hackerskeyboard/commit/2d68c06fbb8adc25bdc91e6715eb43d288ac6b7e
The update fixed it for me.
Thank a lot for your great work! The best keyboard for Android :)
I have installed v1.39.3 now: looks OK.
Thank you!
BTW: although Androidâs âSettingsâ â âAppsâ shows âVersion v1.39.3â, the information in âSettings for Hackerâs Keyboardâ itself shows âVersion 1.39.2-1-gc05fde7 2016-12-10ââI have no idea where that comes from: at least there is no string â1.39.2â in the code anymore and the releases short-hash is â0394abcâ, not âc05fde7â (there is no such commit-hash in the repository, unless I am not mistaken, as well as no such string in the code) (and the leading âgâ is not a hexadecimal digit if I might point that fact out)
Not important, merely curious.
Thank you, again!
Regards,
Kalten
@Kalten666 That's a fair question. I did the release in the wrong order - I should have tagged first and then built, instead I built first before tagging 1.39.3. For the record, I did most of the work for this hotfix on my phone via SSH while in a car, this makes it a bit harder to follow procedures ;-)
The version string is basically just "git describe --tags" output, see https://github.com/klausw/hackerskeyboard/blob/1.39.3/java/AutoVersion.sh .
The -g suffix is normal, see the EXAMPLES section in https://git-scm.com/docs/git-describe. Release c05fde7 was an internal HEAD which didn't exactly match the published 1.39.3, I had amended the commit message after building with no code changes. I've added a new tag to save it for tracking purposes: https://github.com/klausw/hackerskeyboard/releases/tag/1.39.2-1-gc05fde7 .
Edit: github's compare tool seems confused and shows a full commit as a change between these tags. The files are identical on my repo for these tags:
$ git rev-parse 1.39.3
0394abcfe55579a94e7752a536aa41f1e8ef47eb
$ git rev-parse 1.39.2-1-gc05fde7
c05fde72643e59cd3009623bafa57bc3f2c08a70
$ git diff 1.39.2-1-gc05fde7..1.39.3 | diffstat
0 files changed
If you see any differences in a cloned repo please let me know, I think it's just github's UI being weird.
Interesting: git pull did not retrieve 1.39.2-1-gc05fde7âI had to clone again (what did I do wrong?).
git diff 1.39.2-1-gc05fde7..1.39.3 does not show differences in the fresh clone.
Most helpful comment
@Kalten666 That's a fair question. I did the release in the wrong order - I should have tagged first and then built, instead I built first before tagging 1.39.3. For the record, I did most of the work for this hotfix on my phone via SSH while in a car, this makes it a bit harder to follow procedures ;-)
The version string is basically just "git describe --tags" output, see https://github.com/klausw/hackerskeyboard/blob/1.39.3/java/AutoVersion.sh .
The -g suffix is normal, see the EXAMPLES section in https://git-scm.com/docs/git-describe. Release c05fde7 was an internal HEAD which didn't exactly match the published 1.39.3, I had amended the commit message after building with no code changes. I've added a new tag to save it for tracking purposes: https://github.com/klausw/hackerskeyboard/releases/tag/1.39.2-1-gc05fde7 .
Edit: github's compare tool seems confused and shows a full commit as a change between these tags. The files are identical on my repo for these tags:
If you see any differences in a cloned repo please let me know, I think it's just github's UI being weird.