Auto-generated rustdoc for the generated KeyOS API crates — types, functions, methods, traits, and the source view, with working cross-linking and search.

Open the full API Reference →

Where to start

If you're building your first app, these are the high-traffic crates:

• fs — filesystem (FileSystem, File, Dir, Location, OpenFlags)
• quantum_link — post-quantum Bluetooth to a paired companion app
• gui_server_api — register your app with the GUI, draw, animate, handle input
• security — secure element, seed access, device identity
• settings — typed system settings get / set / subscribe
• app_manager — app lifecycle, metadata, third-party certificates

For documentation on all available crates, jump to the API Reference landing .

How the API surface works

Every service crate ships:

• A client handle (e.g. FileSystem, QuantumLinkApi) that owns a checked connection to the corresponding service
• A use_api! macro that wires the handle up against your app's generated permissions type
• A messages submodule with the raw IPC wire types — apps don't use these directly; the client handle is the public surface

The methods on a client handle are bound by where P: MessageAllowed<...> constraints, so the compiler refuses to build if you try to call something you haven't declared in app-config.toml's [permissions] block. The kernel then enforces the same set at runtime.

See Building Apps for the manifest format and KeyOS — Permissions for the security model behind it.