Add Rebol-Server to GitHub CI

[hostilefork]

I began looking at how to add rebol-server to the Android GitHub CI.

It is easier to build the APK on the host than to try and use ADB to automate the emulator to build it in Termux (!) So this means the process has to be adjusted slightly. For instance you do not sudo apt install dx on Ubuntu, you sudo apt install dalvik-exchange. So that is a small twist. Bigger is that you need to have the OpenJDK installed. :-(

Installing an APK on the device with ADB is easy with adb install -g rebol-server.apk. The -g means "grant permissions" which makes it so the emulator won't have UI asking you to allow it to access things.

Launching involves knowing the "package name" and "activity name":

adb shell am start -n giuliolunati.rebolserver/giuliolunati.rebolserver.MainActivity

Right now this throws up a dialog that says "This app was built for an older version of Android and may not work properly." There's a UI button that makes you say OK. It turns out you can dismiss this dialog with:

adb shell input keyevent KEYCODE_BACK

(But clearly the dialog itself is a bad thing. So that's a separate issue.)

I'm not quite sure how we would push the "R3-Console" in the UI to start things. But since the server should be started, we can instead launch a URL programmatically of the R3-Console:

adb shell am start -a android.intent.action.VIEW -d http://localhost:8888/apps/r3-console/index.html

Faking keystrokes to the web console can be done with input keyboard text via the adb shell:

adb shell "input keyboard text 'print {Hello, Android World!}'"

It does not seem to understand \n as newline, so you have to simulate the enter key separately

adb shell input keyevent KEYCODE_ENTER

But if It Works...How Do We Know It Worked?

I can look at this in an emulator on my machine and see it working. But for an automated test on a cloud server with no screen, that's not an option. There has to be some kind of signal coming back that everything succeeded.

One possibility could be running a line of code in the Wasm console causing a HTTP request of the native server, causing it to spit out a file to the /data/local/tmp directory. Then we get that file on the emulated device back to the host, with an adb pull command...and check that the file has in it what is expected.

So this would be a change to %webserver.reb to ask it to do this. Maybe triggered by something like:

adb shell "input keyboard text 'write http://localhost:8888/testwrite reverse {sseccus}'"

Then if a file in /data/local/tmp/test.txt got written with "success" it would mean the console ran, the server ran, and all is probably fine?

[hostilefork]

Woo, it works!!

One possibility could be running a line of code in the Wasm console causing a HTTP request of the native server, causing it to spit out a file to the /data/local/tmp directory.

I gather that at some point the handling of /data/local/tmp got more restrictive. So this wasn't working.

I hacked in a generic hook in webserver.reb which would interpret any web request of /testwrite/xxx/yyy.zzz to mean to try to write a file called /xxx/yyy.zzz. Then I had it trap if there was any error in doing so and report it, so that made it easier to find a place that would be legal to write (that could also be read by ADB).

It turns out that /data/data/giuliolunati.rebolserver/ is a legal directory to write to...and so long as ADB is running with adb root it can also read that path. So that's what I'm using for now.

In terms of source changes, there wasn't all that much needed to get things running:

• Expression barrier | is now a comma ,
• AND and OR are a bit different
• FILE and PATH! now go through a special operation, and directories end in /

But we do need to switch over to using the latest replpad and httpd. A fixed commit probably doesn't make sense. Right now I have the build workflow just overwrite the directories with new enlistments, but the scripts should do better...