Add Android ARM64 release target

[jakebailey]

Fixes #4715
Closes #4729

[Copilot]

Pull request overview

Adds an Android ARM64 package target for native TypeScript releases.

Changes:

• Builds and publishes Android ARM64 binaries.
• Prevents unsafe fanotify probing on Android.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
Herebyfile.mjs	Enables the Android ARM64 release package.
internal/fswatch/fanotify_linux.go	Disables fanotify detection on Android.

[robertkirkman]

Is there a way I can download the GitHub Actions CI artifact from this PR?

[jakebailey]

No, but I could temporarily enable that (it'd be too big overall to have on always)

[robertkirkman]

If it's not too much trouble I would like to test it, but if it would take too long then don't worry about it.

[jakebailey]

Temporarily made this upload artifacts; will undo when you've checked.

[robertkirkman]

Thanks;

When I downloaded the artifact, there doesn't appear to be an Android binary in it, unless I'm confused and I'm missing it, or it's just slightly hidden:

do you know where it went?

extra information about .vsix files

Also, regarding the .vsix files, on Android we have at least 2 distinct native ports of variants of VScode, code-server and code-oss, and it is technically possible to compile custom .vsix files (either containing, or modified to detect, native binaries) in such a way that they become compatible with both of them. I have developed one here,

https://github.com/termux/termux-packages/blob/7c7deb18daf09f7845c640c86c6dea0f33e2b110/x11-packages/codelldb/build.sh

(All .vsix files that do not contain native binaries, which is most, work as-is in our builds of VSCode for Android without rebuilding)

however, I'm not sure exactly whether it would be worth the effort for you to support the VSCode package for Android as well as the NPM package; There are at least a few people using the .vsix file I built and distribute to pkg install code-oss-extension-codelldb, so these builds of VSCode do have users and few of them do use the native .vsix file I built, but I expect the NPM package to have a lot more users in comparison.

[jakebailey]

We're only going to publish VSIXes that vsce lets us work with, so I doubt we'd do more than what we already have.

I forgot that CI only builds the core platforms, so I'll hack android in there quick

[robertkirkman]

I have tested the artifact on F-Droid Termux, and it is fully working there and is able to compile the Typescript Hello World.

However, unfortunately, on Google Play Termux, this error is occurring:

The reason why this error occurs is because typescript-go attempts to detect its installation directory using the os.Executable() function,

typescript-go/internal/bundled/noembed.go

Line 23 in 5b1047d

exe, err := os.Executable()

and unfortunately, in all Android apps that have targetSdkVersion 29 or higher, it is not possible for the executable ELF to get its real executable path from the /proc/self/exe pseudofile, like most programs for desktop Linux and F-Droid Termux are written to do.

https://github.com/golang/go/blob/5d29d80b6c9960c3fc39e14e3e8b9a0f52041fed/src/os/executable_procfs.go#L21

Instead, it is necessary to determine the path that typically would come from /proc/self/exe by reading the contents of the TERMUX_EXEC__PROC_SELF_EXE environment variable, which is automatically set in the environment of each launched executable by the implementation of the exec() function that is globally set in Google Play Termux's LD_PRELOAD environment variable.

[robertkirkman]

For some context: this is a very common problem in Google Play Termux, however it is one of the few very common problems that are only reproducible in Google Play Termux and when it gets resolved within the program code, usually the program fully or mostly otherwise works. Because of that, I estimate that if that problem were solved, there probably would not be any other immediately obvious problems running the binary in Google Play Termux.

The other very common problem with Google Play Termux is that it can't execute fully statically linked binaries, however the binary from this artifact has /system/bin/linker64marked as its interpreter appropriately, and it already is showing an error message from its own code (not an error message from the shell before it can start running), so that means that this binary has already passed the test for that problem.