2023-02-26

This week I worked some on lDebug's getinput as well as on modding the Android app called Hacker's Keyboard.

Upon rewriting the prompt and visible text of the getinput handler, we should keep enabled the highlighting mechanism on int 10h in order to reset the video attribute of the prefix, in case it was highlighted but the visible text has scrolled back to the start of the input.

The problem was that puts reset the highlight flag upon Carriage Returns, so the rewrite would occur with just int 10h function 0Eh, without overwriting the attribute. This happened to work as intended on the serial terminal with its escape sequences, but was noticed on the HP 95LX and subsequently reproduced in dosemu2's -t mode. (ETA: The fix was to reset the flag on Line Feeds only, not Carriage Returns.)

Next, the BEL and CR codepoints caused funny symbols to be displayed. This was fixed by not calling function 09h (to write the attributes) for codepoints below 32, that is for nonprintable ASCII codepoints.

When scrolling the cursor to the right without scrolling the visible text, the redraw handling will now only draw the codepoint at the former cursor position, as opposed to drawing a Carriage Return and all text before the new cursor position. (Or, before the cursor move optimisation, all visible text and then again all text before the new cursor position.)

These optimisations did not change the output or behaviour of the debugger. However, they saved a number of bytes and instructions particularly in the getinput spaghetti code. They were done in small steps to insure that each step can be easily reviewed.

The Hacker's Keyboard app is part of my Android mobile setup. The other part is ConnectBot, an ssh client and terminal app. Together I use them to connect to our Debian server, where most of my 86-DOS-related work happens now.

The first problem of these two apps that I noticed a while ago (2021 November) was that when updating ConnectBot, the keyboard did no longer recognise it for special handling. In particular, Hacker's Keyboard defaults to intercepting Control-A to avoid users accidentally doing Select All on their input. To send a Control-A regardless, Control-Alt-A needs to be entered. ConnectBot was exempted from this however. I relied on this because I'm running GNU screen on the server, which uses Control-A as its hotkey. I had reported this bug to ConnectBot (issue #1038) but nothing came of it.

Writing of nothing, I recently acquired a Nothing Phone (1). Setting it up I was gullible enough to just update it fully, leading to it installing Android 13. On Android 13, however, the keyboard's candidates view didn't work, displaying a white blank bar instead of the orange text on black background candidates view. I found that others had the same problem, documented in an issue to the hackerskeyboard repo, though no new development seemed to be forthcoming there. A related Google bug report was linked on that issue, which in 2023 February had an official state that there was no bug in the system; rather, the apps should be changed to correctly work on Android 13 systems.

So that was two bugs involving the keyboard app, and the second one didn't have any practical workaround. Therefore, I set out to build and modify hackerskeyboard.

The first attempt was in the week before, where I downloaded and installed Android Studio as well as an SDK and NDK on the amd64 Linux box. However, I received some cryptic errors and did not manage to build the app that time.

Then, last Thursday I had been in contact with an acquaintance to correct them on a few errors. I asked whether they knew their way around building Android apps. Albeit they replied that their experiences were from years ago, they agreed to look at what errors I might get.

To be honest, they weren't much of a help, but they did motivate me to get into it again. All said I spent about 3 hours that day. The breakthrough was to open the Project Structure dialogue, select its Project tab, and change around the Gradle versions. In particular, I changed the "Android Gradle Plugin Version" to increase it to 4.0.0, and decreased the "Gradle Version" to 6.9.4. This caused the IDE to download a bunch more of packages. And, finally, the cryptic errors were no more and the build went somewhere.

The next problem was an error about the targetted SDK version being too low for the Google play store. I quickly found that the IDE provided a tooltip menu with the option to ignore this error, which inserted a comment in the configuration file which specifically disabled that check. I wasn't after uploading it to the store anyway.

After that, I was surprised to find I could now build a debug APK file. Transfer to the new mobile proved difficult, but I was able to upload the APK to our server, download it again to the mobile, and install it that way. This required allowlisting, I think, the browser as a source for installing apps. Then during installation a popup occurs stating the app is unknown. This requires expanding a line for more options, revealing an option to install anyway. Briefly after that, another popup asks whether to send in the app for Google to check it, which presents us with three options: "Yes", or "Yes, always, and don't ask again", or "No, not this time" (from memory, not exact quotes). I'm a little annoyed that there is no option to dismiss this question permanently.

At the tail end of that day, I also attempted to connect the device to the IDE using wireless or USB debugging. However, both failed variously. I next tried to transfer the APK file using USB file transfer mode. This repeatedly hung the file manager on the desktop, however.

The next day (Friday), the first order was figuring out USB file transfer. Turns out the port or the cable I had tried were no good. Trying with another cable (which was very short) on one of the front (USB 2) ports of the desktop box it worked fine. Next, I had to do the dance to allow the file manager app on the mobile to install apps.

I had noticed that after installing the hackerskeyboard app from my build, it did not appear to send the "toast" (a popup notification) about the Control-A interception. Other than this it did handle Control-A exactly as expected. I first suspected some resources problem, as I'd seen a few messages about that fly by on the build. However, when I managed to find those again I found that the Control-A message resource was not among them. It turned out that I simply had to enable notifications from my app in the system's app settings.

That led to my first actual modification of the app: I added a StringBuilder object to the place of this toast and appended the text " ecm was here!!!" to the original message. It was an instant success (photo file).

The next order was to add some debugging info to this toast, in order to aid fixing the ConnectBot bug. I replaced the original message by just "C-A." to avoid overflowing the visible text of the toast. Next I added the display of the current app's name and input type.

I took a dare on being able to fix the ConnectBot bug, and updated ConnectBot to the most recent version available from the F-Droid repo. (Downgrading versions of ConnectBot from F-Droid has failed in the past.) Sure enough the bug did happen with that version too, seeing as the developers did not address my bug report. And I was able to glean the changed input type number from my debugging aid. Adding this to the "is ConnectBot?" function seems to have fixed this bug.

The next bug to work on was the blank candidates view. I had anticipated this to be another easy fix. (Certainly easier than getting it to build at all.) It did take considerable effort after all. The instructions stated in the Google bug report were clear, but they didn't lead to success. It only worked once I despaired so much that I had it call the super class's methods, rather than the methods of our own class. This seemed to be just the knack needed to make it work. After another two hours I called it a day.

On Saturday, I noticed that with my modified app installed, some apps required a double tap on the Back button to actually perform the back action. In particular this seemed to occur whenever the keyboard wasn't visible at all. First I disabled the app to insure it was the cause of this. It was.

Next, I tried some minor changes without any success. However, I soon found someone else had described a similar problem in the ever-helpful Google bug report. I tried their first solution, appending a hide method call to our onStartInput method. This fixed the double-tap problem.

However, it appears that it introduced another problem: Whenever I send a message using the blabber.im app, the keyboard now disappears and re-appears quickly. I consider this annoying, but less so than the double-tap Back bug. Maybe I'll be able to work around this too, in time. (ETA: Seems to have been fixed by a subsequent revision I did today.)

So that's where we are right now.

(Oh, I forgot to mention that the USB A-to-C cable that failed did eventually work after I connected it to another port.)