BluetoothThe set of APIs for managing and communicating via Bluetooth. This includes both connecting peer devices, searching for devices, advertising the local device, and communicating or interacting via Bluetooth profiles. Generally once connected, Bluetooth capabilities will be exposed through APIs in other sections, and this API only exposes surfaces for connecting, managing discovery and pairing, and Low Energy protocols which are often custom to each device.
Often specific Bluetooth Profiles provide an API for system services to use for status and control as well.
Component FrameworkThe set of APIs that are used to define components, interact with components, and integrate with the Component Framework. These are the low level APIs for interfacing with the Component Framework -- in some cases they may be used by developers directly, but they may also be used to build higher level APIs such as Session Framework.
DeveloperDeveloper tool interfaces, such as the Command-line Tools Rubric. APIs that affect the developer experience in the host environment such as debugging, forensics, or the development kit.
DiagnosticsThe set of APIs that are used to publish and query diagnostics data from components on the system. This includes the ability to stream logs, view and publish Inspect data, and observe lifecycle events.
DriversThe set of APIs used to communicate with various drivers that interact with hardware or other drivers. The apis are accessible by opening the device using a devfs path, such as
/dev/class/<protocol the device exposes>/<incremental number>.
Most of the APIs exposed by drivers are in the
Other APIs are distributed under the corresponding area (e.g. Bluetooth, WLAN,
Graphics, HCI) that the driver tackles. Although these APIs do not live under
fuchisa.hardware.* namespace they might interact with hardware, or other
drivers that interact with hardware.
Driver SDKThe set of APIs used to interact with devices via the driver manager. This may be used by developers to retrieve information about a device or change its current state.
ExperiencesThe set of APIs used to create user experiences. These include the set of APIs that facilitate user interactions that are common across multiple products.
FIDLSince most APIs are expressed in FIDL, the FIDL area is cross-cutting with the goal to both support all other areas, and leverage their experience to inform the future direction of the FIDL language and ecosystem.
FirmwareA small set of libraries necessary for firmware to boot Zircon, for example ZBI image handling, A/B/R boot metadata, verified boot. Essentially, this defines the contract for how the bootloader communicates with Zircon.
As firmware runs outside of Fuchsia, this is not generally meant for Fuchsia end-developers, but instead for bringing up Fuchsia on new platforms. These libraries together form the "Firmware SDK" which is then ported to a specific platform's firmware codebase.
GraphicsThe set of APIs that are used to transport and compose images on the system. It includes interfaces for communicating with graphics hardware, as well as scene-graph communication between Scenic and the rest of the system (not including higher-level concepts such as views, see the View System area for that).
HCICovers input, accessibility, internationalization.
The set of APIs that connect human–computer interaction (HCI) devices starting from drivers, to filtering, semantic understanding, grouping, routing, all the way to delivering these inputs to the View System. This includes APIs associated with touch, mouse, keyboard, text editing and the accessibility framework.
IdentityThe set of APIs used to manage user accounts, authentication, and identity information for service providers.
KernelThe Fuchsia kernel, whose API surface is:
- The set of syscalls and the set of types and constants associated with these syscalls. Those APIs are defined in //zircon/vdso/ and //zircon/system/public/zircon/.
- The interface with bootloaders, the most important being the ZBI.
- The BOOTFS image and the ABI of the binaries within.
MediaThe set of APIs used to capture, process and render audio and video streams. The media APIs also encompass adjacent concerns such as volume control and media session management.
MetricsThe set of APIs that allow clients to log events that are associated with metrics. These events are collected off-device, and can later be analyzed across many devices.
NetstackThe set of APIs enabling networking in Fuchsia. Encompasses APIs that drive the data, control, and management planes of networking ranging from contracts with device drivers to auxiliary application-level protocol services.
- fuchsia.hardware.network, data plane contract with device drivers.
- fuchsia.posix.socket, POSIX sockets API.
- fuchsia.net.interfaces, Interface management plane.
- fuchsia.net.name, Application level name resolution.
SecurityThe set of APIs used to directly interact with security features (for example cryptographic key management) or tools (for example fuzzers).
SessionsA set of APIs to coordinate a product’s user experience. Specifically the API contains protocols for communicating with the session component.
- The session may ask a window manager to display a component view via GraphicalPresenter.
- The session may implement ElementManager to receive requests to add components to the session. A developer may use Restarter to restart a running session.
The session API often makes use of protocols and data structures defined in
other areas of the platform. For example,
GraphicalPresenter does not define
its own view type. Instead, it uses
ViewRef from the View
System to identify component views.
StorageStorage is a combination of the following APIs:
These libraries are the common way for service discovery, filesystem access, and capability sharing on Fuchsia.
They are used primarily for client interaction with the filesystem, where a client can be any component/process in the system that needs to access files/directories in a filesystem.
Used for finding block devices, starting filesystem processes to service these block devices, and providing handles for these file systems to the rest of Fuchsia.
Filesystem specific APIs, used for operations specific to a filesystem.
fuchsia.fs, responsible for providing administration functionality for filesystems.
View SystemThe set of APIs that need to reason about and interact with visual regions ("views") and their lifecycle. They generally are not tied to a particular graphical representation, but some have close ties to graphics APIs. HCI APIs are built on top of the View System.
- fuchsia.ui.app, in particular ViewProvider
- view/scene connection signals in fuchsia.ui.gfx.Event
VirtualizationVirtualization is the combination of:
- The hypervisor, which is implemented by the Zircon kernel, and provides the execution environment for a virtual machine. Specifically, it provides address space isolation, trapping of access to memory or IO port addresses, and management of virtual CPUs.
- The virtual machine manager, which uses the hypervisor in order to provide a complete virtual machine for an operating system to run within. This includes the emulation of hardware, as well as the loading and execution of the operating system itself. It provides a bridge between the guest operating system running within the virtual machine, and services within the host operating system, such as storage, networking, and graphics.
- fuchsia.net.http, supports basic interactions (e.g. GET, PUT) with HTTP-based services.
- fuchsia.url, defines web-standard URL type, and limits.
An implementation provided by the Chromium project is included in the Fuchsia repository as a pre-built package.