Libraries

Libraries expose reusable contracts, types, protocols, algorithms, adapters and concrete implementations without owning an independently installed runtime service. They may be internally stateful or use subsystem interfaces; architectural ownership and lifecycle determine placement.

Common foundations

• Shared: portable shared types and helpers. shared crate.
• Synchronization: synchronization abstractions. synchronization crate.
• Target: target/build configuration utilities. target crate.
• Internationalization: external embedded-i18n integration and build-time locales. embedded_i18n crate.

Contracts and implementations

• File system: filesystem, path and device I/O contracts. file_system crate.
• LittleFS: concrete embedded filesystem implementation. little_fs crate.
• Device: device-control and backend-independent neural-network inference contracts. device crate.
• Debug protocol: headless diagnostics requests, UI input and screenshot frame validation. debug_protocol crate.
• Peripherals: embedded-hal GPIO contract and fixed-capacity mock. peripherals crate.
• Audio: bounded PCM device contract, buffers and mixer implementation. audio crate.

Execution and support

• ABI: C declarations, exports and interoperability contracts.
• Executable: executable protocol, context and launcher helpers. executable crate.
• Application metadata: shared guest/native application inventory and shortcut metadata. application_metadata crate.
• Authentication: reusable credential/verification operations. authentication crate.
• Bootsplash: startup animation implementation. bootsplash crate.
• Testing: test assembly helpers.

See Subsystems for runtime owners, Drivers for target implementations and Executables for launched programs and Wasmi integration.

Library API boundaries

Each page describes what code may rely on, how resources and lifetimes are managed, and what remains incomplete. Distinguish the named Cargo crate from the runtime owner: for example, audio manages caller-owned PCM streams while Graphics owns the active LVGL runtime.

For code links, the Core repository uses libraries/<crate>/ after Core #457. The eight runtime-owned services instead live under subsystems/. Internationalization is an external embedded-i18n integration, not a separate first-party crate, so use its page for build-time locale workflows.

When extending one of these APIs, check the direct source links in its page and the generated host Rustdoc for exact method names, feature gates, preconditions, error types and ownership constraints.