Skip to main content

Cabin documentation

Authoritative documentation for Cabin, an open-source AAOS design language and dual UI component library (Jetpack Compose + legacy Views).

Library Alpha: cabin-tokens, cabin-compliance, and Theme Kit in cabin-views. Planned APIs beyond that are marked as such.

Table of contents

Orientation

DocumentDescription
VisionPositioning, uniqueness vs Material, OEM/Tier-1/dev adoption
PrinciplesClean Code, SOLID, safety-critical UI, android/skills alignment
ArchitectureMulti-module plan, dependency rules, theming, anti-bloat
RoadmapPhased delivery aligned to the product feature layers
ContributingContribution guide

Pre-implementation (before library code)

DocumentDescription
Pre-implementation gateChecklist before writing library source
MVP v0.1Frozen scope: tokens + restriction + Theme Kit + two bars (Views-first)
API contractsMaven, Soong names, packages, semver
Support matrixPlanned API / AAOS / build-tree targets
Testingv0.1 unit, Views, CI vs Soong expectations
ADRsArchitecture decision records

Product

DocumentDescription
Product indexProduct design docs — stance, pillars, feature plan
StanceCalm, legible, inevitable cabin HMI
PillarsFive gates every feature must pass
FeaturesLayered feature plan (Foundations → Craft)

Compliance (first-class)

DocumentDescription
Compliance overviewHow compliance is modeled and enforced
Restriction statesMVP state machine + System/Status Bar matrix
Driving restrictionsDistraction minimization, gated interactions
UX restrictionsTouch targets, density, contrast, day/night
Accessibility & glanceabilityFont size, readability, driver glance patterns
Safety-critical UIDeterministic behavior, fail-safe defaults

Design language

DocumentDescription
OverviewCabin design language scope
FoundationsColor, type, space, elevation, motion, icons
TokensSemantic + component tokens, OEM theming without forks
Token schemaJSON stub, naming, overlay/RRO mapping

Components

DocumentDescription
InventoryTaxonomy and coverage map
System barsNav / system chrome
Status barsVehicle and system status
Spec: System BarMVP implementable spec
Spec: Status BarMVP implementable spec
MediaPlayback, browse, now-playing
EVRange, charge, energy
HVACClimate zones and controls
Vehicle controlsDoors, lights, drive modes, etc.
Extension modelOEM custom screens on Cabin rails

Platforms

DocumentDescription
ComposeCompose guidelines and Views parity contracts
ViewsView/XML for SystemUI and build-tree apps
SoongPlatform Soong engineering notes (Android.bp)

Adoption

DocumentDescription
IntegrationAdd Cabin to an existing AAOS/app repo
Theme KitViews Theme Kit + OEM overlay / RRO path (MVP #3)
Build-tree / SoongSystemUI, CarLauncher, platform media via Soong
MigrationFrom stock Material / AAOS widgets
PackagingMaven vs Soong dual distribution, minimal footprint

Agents

DocumentDescription
Agents indexAGENTS.md, skills/, Cursor rules, android/skills relationship
AGENTS.mdHard rules for coding agents (repo root)
llms.txtLLM-oriented doc map
skills/Modular Agent Skills (SKILL.md per concern)

Website

DocumentDescription
website/Public docs shell (Docusaurus) — run/build/deploy
Site planPublic docs IA modeled on m3.material.io
Marketing craftDocs vs marketing roles; points to apps/www/DESIGN.md

How to read these docs

  1. Start with vision and the product stance.
  2. Filter ideas through pillars and the feature plan.
  3. Before library code: pre-implementation and MVP.
  4. Internalize compliance — it constrains every component.
  5. Learn tokens / token schema before implementing UI.
  6. Pick a platform (Compose or Views) and keep parity contracts in mind. Platform chrome uses Soong — build-tree.
  7. Use architecture and packaging when wiring modules into a product.

Dual stack reminder

Every component and pattern is specified for both:

  • Jetpack Compose (cabin-compose, Experimental Theme + bars)
  • Legacy Views / XML (cabin-views, planned)

Shared tokens and compliance live outside both UI stacks so OEMs can theme once and ship everywhere. See architecture.