Areas

Bluetooth

Primary: jamuraa@google.com
Secondary: silberst@google.com

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:

Component Framework

Primary: geb@google.com
Secondary: dgilhooley@google.com

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

Primary: wilkinsonclay@google.com
Secondary: chaselatta@google.com

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.

Diagnostics

Primary: crjohns@google.com
Secondary: miguelfrde@google.com

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:

Drivers

Primary: cja@google.com
Secondary: jocelyndang@google.com

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 /dev/class/<protocol the device exposes>/<incremental number>.

Most of the APIs exposed by drivers are in the fuchsia.hardware.* namespaces.

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 fuchsia.hardware.* namespace they might interact with hardware, or other drivers that interact with hardware.

Examples:

Driver SDK

Primary: jocelyndang@google.com
Secondary: surajmalhotra@google.com

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:

Experiences

Primary: chaselatta@google.com
Secondary: ianloic@google.com

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:

FIDL

Primary: ianloic@google.com

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.

Firmware

Primary: dpursell@google.com

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

Primary: lindkvist@google.com
Secondary: qsr@google.com

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:

Graphics

Primary: costan@google.com
Secondary: emircan@google.com

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:

HCI

Primary: neelsa@google.com
Secondary: emircan@google.com

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:

Identity

Primary:

The set of APIs used to manage user accounts, authentication, and identity information.

Examples:

Kernel

Primary: cpu@google.com
Secondary: abarth@google.com

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 //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.

Media

Primary: dalesat@google.com
Secondary: ypomortsev@google.com

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:

Metrics

Primary: frousseau@google.com

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:

Netstack

Primary: brunodalbo@google.com

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:

Power

Primary: mbrunson@google.com
Secondary: prashanthsw@google.com

The set of APIs for centralized power and thermal management, including system power state control, administration of power dependencies, and thermal throttling. Also includes aspects of power delivery such as battery management.

Naturally overlaps with other API areas on power/thermal-related drivers and subsystem-specific power management APIs. Ownership of overlapping APIs is deferred to other API areas where practical, with the Power area operating in a consulting role.

Examples:

Product Assembly

Primary: aaronwood@google.com
Secondary: awolter@google.com

A set of APIs to combine software from a variety of sources into a flashable, updatable product image. Product Assembly is concerned with:

  • The assembly-time product/platform interface, which allows product owners to specify how the platform should be configured for a particular product.
  • The contract for how assembly input artifacts are specified to the assembly tools which assemble the correct set of artifacts for a given product build.

Security

Primary:

The set of APIs used to directly interact with security features (for example cryptographic key management) or tools (for example fuzzers).

Examples:

Sessions

Primary: quiche@google.com
Secondary: neelsa@google.com

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.

Examples:

Software Delivery

Primary: galbanum@google.com
Secondary: etryzelaar@google.com

The Software Delivery team manages software packaging and updates for Fuchsia devices.

Storage

Primary: csuter@google.com

Storage is a combination of the following APIs:

  • fuchsia.io

    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.

  • fuchsia.fshost

    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.

    Examples:

  • fuchsia.fs, responsible for providing administration functionality for filesystems.

Testing

Primary: anmittal@google.com
Secondary: crjohns@google.com

The set of APIs responsible for executing, observing, and returning the results of tests executed on a device. These APIs abstract over different test frameworks and tools to provide a FIDL interface for testing use cases on Fuchsia.

Examples:

Toolchain

Primary: mcgrathr@google.com
Secondary: phosek@google.com

No description available.

View System

Primary: emircan@google.com
Secondary: neelsa@google.com

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:

Virtualization

Primary:

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.

Web

Primary: wez@google.com
Secondary: ianloic@google.com

Web encompasses APIs for working with standard web protocols (e.g. HTTP, HTTP2), content types (e.g. HTML) and application run-time technologies (e.g. JavaScript, WebAssembly). Functional interfaces (e.g. fuchsia.web , fuchsia.net.http ) typically replace functionality that would otherwise need to be bundled as a library into each individual client package.

Examples:

  • fuchsia.net.http supports basic interactions (e.g. GET, PUT) with HTTP-based services.
  • fuchsia.url defines web-standard URL type, and limits.
  • fuchsia.web

    allows component instances to be created to host content created using standard web technologies (HTML, JavaScript, etc). These are used in a similar way to in-process web-rendering libraries, with the benefit of stronger isolation from the calling application.

    An implementation provided by the Chromium project is included in the Fuchsia repository as a pre-built package.

WLAN

Primary: silberst@google.com
Secondary: jamuraa@google.com

No description available.