The 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.Examples:
The 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.Examples:
Developer 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.
The 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.Examples:
The 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
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
fuchsia.hardware.* namespace they might interact
with hardware, or other drivers that interact with hardware.
The 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.Examples:
The set of APIs used to create user experiences. These include the set of APIs that facilitate user interactions that are common across multiple products.Examples:
Since 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.
A 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.Examples:
Foreign ABI Compatibility
The set of APIs used to run and interact with programs compiled for other operating systems.
Currently this covers the Starnix (Linux binary compatibility) APIs.Examples:
- fuchsia.starnix.developer Protocols for starting a component containing an unmodified Linux binary.
The 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).Examples:
Covers 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.Examples:
The set of APIs used to manage user accounts, authentication, and identity information.Examples:
The 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
- The interface with bootloaders, the most important being the ZBI .
- The BOOTFS image and the ABI of the binaries within.
The 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.Examples:
The 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.Examples:
The 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.Examples:
- 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.
The set of APIs used to directly interact with security features (for example cryptographic key management) or tools (for example fuzzers).Examples:
A set of APIs to coordinate a product's user experience. Specifically the API contains protocols for communicating with the session component.
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.
No description available.
Storage is a combination of the following APIs:
Describes the common means of 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.
No description available.
The 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.Examples:
- fuchsia.ui.app In particular ViewProvider
- View/scene connection signals in fuchsia.ui.gfx.Event
Virtualization 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.
No description available.