SysLink

SysLink is a general-purpose protocol and set of components for exposing operating-system services to another process. A backend, SysLink Core, performs operations on behalf of a client, while client libraries present those remote operations through APIs natural to their language and platform.

The project was originally created to let applications reuse a privileged su process on Android for many operations. It also avoids depending on the particular versions and behavior of command-line utilities supplied by Toolbox, BusyBox, Toybox, or similar toolsets. Instead, Core provides consistent, structured access to system functionality including filesystem operations, process execution, and optional Android Binder support. This does not require injecting code into Android framework internals.

Android remains an important use case, but it is not a boundary of the design. The protocol is platform-neutral enough to support other operating systems, deployment models, and applications that need structured access to services in another process.

Current minimum Android API source target is 28 (Android 9), although it may work down to API 26 (Android 8), but this has not been completly confirmed. It is however confirmed to break below 26.

Architecture

SysLink is deliberately divided into two sides:

• Core is the service backend. It owns and operates on system resources in its environment and implements the canonical SysLink protocol.
• Client libraries manage the transport and expose Core's services as convenient APIs to applications.

Core and its clients are not assumed to run on the same device. The current implementation communicates through the Core process's standard input and standard output, and there is not yet a network transport adapter, but neither the protocol nor its resource model depends on process co-location.

This separation is intentional and is a permanent design constraint. Features must not rely on injecting process-local objects or implementation details from one side into the other. For example, SysLink does not push a native file descriptor from Core into a client process, or from a client into Core. Where the protocol exposes a file-descriptor capability, it is an opaque, session-scoped reference to a resource retained and operated on by Core—not a transfer of the underlying native descriptor. New features must preserve this boundary so that the same protocol semantics remain possible across machines and transports.

Capabilities

SysLink currently provides:

• Structured filesystem access, including metadata, traversal, links, copying, moving, removal, and streamed seekable file I/O
• Process execution with environment control, standard streams, signals, and exit status
• Multiplexed, flow-controlled channels for stateful and streaming operations
• Isolated sessions that own resources and provide deterministic cleanup
• Optional Android Binder access when supported by Core and the client library
• Typed protocol and operating-system errors instead of parsing command output

The design keeps platform-dependent work in Core and avoids making the client depend on whichever shell tools happen to be installed on the target system.

Repository layout

• core/ contains the Go backend and canonical protocol definitions.
• libsyslink/ contains the Kotlin/Java client library.
• test/ contains the non-Android integration test client that runs the JVM library against the real Core backend.

Each directory has its own README with component-specific build instructions, API details, and protocol documentation.

Project status

The current client library targets the JVM, while the protocol is designed to support additional client implementations and transports without weakening the separation between Core and its clients.