← Back

NAGARA AI OS Transition Readiness

NAGARA is being built as a gradual Android replacement layer: cloud control plane → native device agent → Android system-service bridge → AOSP distribution.

Current classification: hardened control-plane prototype

This source does not compile AOSP, expose a production runner API, execute ADB/fastboot, or replace Android on hardware. Readiness is no longer determined by browser checkboxes; official build gating uses server-verified evidence.

Implementation status

Implemented in source
Implemented
  • •Authenticated organization and project context without hardcoded demo tenants
  • •Composite organization/project integrity constraints
  • •Evidence-backed AI OS readiness registry
  • •Atomic readiness snapshot and build-job queue function
  • •Server-validated flashing simulation with artifact hash matching
  • •Serialized append-only audit chain with server-derived actor
  • •Device registry and native-agent data-contract foundation
  • •Baseline HTTP security headers and automated P0 regression tests
Foundation only
In progress
  • •Native Android agent enrollment and signed device API
  • •Per-runner credentials, nonce replay protection, and real runner endpoints
  • •Artifact provenance, signature verification, SBOM, and quarantine workflow
  • •Approval-based release, OTA canary rollout, health pause, and rollback
  • •Granular action permissions beyond the original broad writer role
Not yet implemented
Blocked
  • •Privileged Kotlin device agent installed on Android hardware
  • •NAGARA Binder services, SystemUI, Settings, and SELinux domains in AOSP
  • •Full AOSP source, device tree, kernel, vendor blobs, modem firmware, and recovery
  • •Production AVB and OTA keys stored in HSM
  • •CTS, VTS, GTS, first-boot, battery, thermal, and rollback validation on target devices
  • •Signed flashable NAGARA ROM or certified Android replacement image

Build and ROM gate

How gating works

A build job is created only by the database function queue_build_with_readiness after every active blocker and required item has non-expired evidence with status verified.

Producing a flashable ROM still requires external Linux build infrastructure, legal vendor components, supported hardware, signing infrastructure, compatibility testing, recovery, OTA, and rollback validation.

Enter control centerBack to home