Reverse Camera Pipeline (EVS)

The External View System (EVS) Architecture

In modern vehicles, the rearview camera must be operational almost immediately upon turning the key, often within 2 seconds. The standard Android Camera API (camera2) and SurfaceFlinger rendering pipeline are far too slow to meet this strict regulatory requirement during a cold boot.

To solve this, Android Automotive OS introduces the External View System (EVS). EVS is a specialized, low-latency camera pipeline designed to bypass the heavy Android framework and render video directly to the display hardware as early as possible in the boot process.

The EVS HAL: IEvsCamera and IEvsDisplay

The foundation of EVS is its Hardware Abstraction Layer (HAL). It consists of several key AIDL interfaces:

IEvsEnumerator

Acts as the factory for discovering available cameras and displays. It provides methods to query camera metadata and open specific devices.

IEvsCamera

Represents a physical or virtual camera stream. EVS bypasses the complex ISP (Image Signal Processor) configurations found in standard mobile cameras, focusing solely on grabbing raw or YUV frames as fast as possible.

IEvsDisplay

Represents the target display. EVS claims the display hardware directly, bypassing SurfaceFlinger entirely during the early boot phase. Once the main Android OS boots and the user shifts out of reverse, EVS releases the display back to SurfaceFlinger.

// Conceptual C++ EVS HAL interaction
sp<IEvsEnumerator> evs = IEvsEnumerator::getService();

// Open the rearview camera
sp<IEvsCamera> camera = evs->openCamera("rearview_cam");

// Claim the display exclusively
sp<IEvsDisplay> display = evs->openDisplay(0);
display->setDisplayState(DisplayState::ON);

// Route camera frames to the display
camera->setMaxFramesInFlight(2);
camera->startVideoStream(new MyEvsCameraStream(display));

The EVS Manager

While the HAL handles the lowest level hardware interactions, the EVS Manager (evsmanagerd) is a system daemon that acts as a multiplexer.

If multiple clients want to access the same camera (e.g., the rearview app and a computer vision process analyzing the feed for obstacles), the EVS Manager duplicates the frame buffers and distributes them, ensuring that the hardware camera is only opened once.

The Surround View Use Case

Modern vehicles often stitch multiple camera feeds (front, rear, left, right) into a top-down "bird's-eye" view.

EVS supports this via the IEvsUltrasonicsArray and specialized logical cameras. The EVS Manager can take four physical IEvsCamera streams and pass them to a vendor specific stitching algorithm, exposing the composite result as a single, virtual IEvsCamera to the application layer.

Integration with VHAL (Gear Selection)

The EVS pipeline does not trigger itself. It relies heavily on the Vehicle HAL (VHAL).

A typical evs_app (a native C++ application started by init.rc early in boot) subscribes to the VHAL property VehicleProperty::GEAR_SELECTION.

// Conceptual trigger logic in the EVS application
void onPropertyValueChanged(const VehiclePropValue& value) {
    if (value.prop == toInt(VehicleProperty::GEAR_SELECTION)) {
        int32_t gear = value.value.int32Values[0];
        
        if (gear == toInt(VehicleGear::GEAR_REVERSE)) {
            // User shifted to Reverse!
            // 1. Claim EVS display
            // 2. Start EVS camera stream
        } else {
            // User shifted to Drive/Park
            // 1. Stop EVS camera stream
            // 2. Return display control to SurfaceFlinger
        }
    }
}

Because this logic runs as a native daemon, it can respond to a gear shift into reverse long before the Java SystemServer has finished booting, satisfying strict safety regulations for rearview camera latency.