Starboard - RetroBIOS¶
Technical notes
Catalogue manager and execution environment for the PortMaster library on Android ARM64 handhelds. PortMaster ports are Linux ARM64 builds, so nothing is emulated: proot opens a userspace chroot into a Debian bookworm root filesystem and the games run there as native binaries against glibc, SDL2 and Mesa. ES-DE reaches it through the ports system, passing a .port file as the port_file extra to org.force9.starboard/.ui.game.GameActivity.
The build read here is the signed release Starboard-v0.23.0.apk, sha256 a81b69d471ee88ad6c47497e616c5a7c68bf8ebfb32bc7ae9348ed46c3190b3d, matching the digest GitHub records for the asset. The source is not published, so the readings below cite a jadx decompilation of classes.dex taken with --show-bad-code, where org.force9.starboard.* keeps its names and the rest is r8 output under defpackage.
The APK carries its own execution stack in lib/arm64-v8a: libproot.so, libproot_loader.so and libtalloc2.so mirrored from Termux through get-starboard/starboard-prebuilts, libSDL2_starboard.so preloaded ahead of the SDL2 in the rootfs, libasound_module_pcm_starboard.so as the ALSA output plugin, libGLESv2_wrap.so with libvirgl_vtest.so and libvirglrenderer_sb.so for the per-port GPU path, libandroid-shmem.so, and libgame_bridge.so which starts proot and builds the PortMaster environment. Android installs all of them with the package.
What the ports find under /opt/system/Tools/PortMaster is written at launch by libgame_bridge.so: bind_directories.sh, patch_ld_preload.sh, seed_retroarch_cfg.sh and launcher.sh under /tmp/sb, the gptokeyb shim, runtimes.json, control.txt and device_info.txt, with etc/resolv.conf and etc/hosts seeded straight after extraction. The ES-DE sync writes the .port files it later launches from, each holding a zip_name and a launcher key, along with a ports entry in custom_systems/es_systems.xml and gamelists/ports/gamelist.xml.
Games install to Starboard/ports on shared storage, marked by a .starboard_installed file, and come from the PortMaster catalogue rather than from this profile. A port that declares a runtime pulls a squashfs image into opt/system/Tools/PortMaster/libs inside the rootfs on first launch, named by the port and resolved through the utils index of PortsMaster/PortMaster-New filtered to arch aarch64. Starboard names no runtime of its own and that index is republished with the catalogue, so the set belongs to PortMaster.
1 files | 1 required, 0 optional | 0 in repo, 1 missing Categories: 1 game data
starboard-rootfs.tar.gz required missing game_data
Debian bookworm ARM64 root filesystem the ports execute in
- Path:
rootfs.tar.gz - Size: 555.1 MB
- SHA256:
a40dd11b2480... - Aliases:
rootfs.tar.gz - Validation: sha256
- Source:
Starboard 0.23.0 ze0.java:75,Starboard 0.23.0 ze0.java:421-422,xe0.java:66-70,ze0.java:236-342,ze0.java:130-144,ze0.java:416-418,ze0.java:426-428,ze0.java:439-463 - Fetched from releases/latest/download of get-starboard/starboard-runtime, written to the cache directory as rootfs.tar.gz, gunzipped into a rootfs directory under internal storage, then deleted. Nothing launches without it: the gate reads usr/bin/env and bin/sh in the extracted tree beside libproot.so in the native library directory. Integrity comes from a .sha256 sidecar requested next to the asset, whose first whitespace token must be 64 hex characters; the file is hashed and dropped on a mismatch, while a missing sidecar logs "No rootfs checksum sidecar available" and the download is kept on TLS trust alone, which is what happens today since that sidecar answers 404. The size and hash recorded here identify release starboard-rootfs-20260604.1, the one that URL served at profiling time, and the app follows whatever release is latest. Its own version is read back from etc/starboard-release, which carries release, commit and built keys.
Generated on 2026-08-23T16:12:06Z