A readable temperature is not a successful climate command

The number changes before the result arrives

Consider a driver-facing climate control showing a target of 21°C. The user selects 22°C. The UI changes the number at once, a call returns without an immediate transport error, and the spinner disappears. Has the climate command succeeded?

That depends on what the UI promised. It may have acknowledged the tap, received a request result, or obtained a new reported target. Those are different events. None, by itself, establishes that the cabin has warmed to 22°C.

For this example, assume the target system supports the requested area, exposes a writable target property, and grants the integrating component the required access. These assumptions belong in the review setup. They are not capabilities that a regular downloaded app can assume.

I would keep the last reported target visible while showing the requested target as pending. An optimistic number can also work, provided the UI distinguishes it from confirmed state and resolves failure. The defect to avoid is letting a temporary interaction response become the permanent account of what the vehicle did.

Check the property before interpreting its value

Android defines HVAC_TEMPERATURE_SET as a target temperature in Celsius. It is a seat-area Float property with on-change reporting; the documented access options include read/write and read-only. HVAC_TEMPERATURE_CURRENT is a separate, read-only current-temperature property. Both require the documented climate-control permission. [1]. [4] [5]

The supported target values may be discrete. Where provided, the temperature-suggestion property or configuration array supplies the supported choices and conversions. A minimum and maximum alone do not justify offering every value between them. The current documentation also includes newer range APIs, so the implementation must match the target platform version rather than copy the newest example into an older integration. [1].

In a review, ask the adapter owner to identify the exact property and area behind the widget. Then compare the offered increments with that area's supported values. This catches a different class of problem from request handling: a polished temperature picker may be offering values that its backend cannot represent as intended.

A readable value does not predict the next write

In AIDL VHAL, VehiclePropValue.status describes availability for reading. An AVAILABLE value does not guarantee that a write is currently possible; a non-available value must not be treated as valid data. [2].

This distinction changes the error path. If the last target remains readable while a new request fails, replacing the displayed number with an indiscriminate “unavailable” state throws away useful information. Keep the valid reported target, explain that the requested change failed, and let the product's retry policy decide what to offer next. This is a UI proposal, not an Android-mandated presentation.

Conversely, when the reported value itself becomes unavailable, retaining a bare number can mislead. A retained historical value needs an explicit stale-state treatment. Reading validity and command progress need separate representation even when both ultimately appear in one compact control.

Follow the callback, then interpret what it means

setValues is asynchronous. Its method return is separate from the result delivered through onSetValues. Property updates arrive through onPropertyEvent; those events describe reported changes rather than automatically proving that a particular UI request caused them. [2].

Suppose the request result reports success and the target property subsequently reports 22°C for the intended area. The defensible presentation is a reported target of 22°C. Showing “cabin warmed” would require evidence about the measured condition and a product definition of completion that the target-setting property does not supply.

Also consider a second client. A physical control or another authorized component might change the target while this UI has a request outstanding. Store request progress separately from reported state so that the later event can update the display without inventing ownership of the change. Do not impose a callback-before-event ordering unless the relevant contract guarantees it.

A completed review matrix

The following judgments are proposed review outcomes. They are not results from an emulator or vehicle, and they do not prescribe the supplier's transport or retry implementation.

One additional product decision deserves an explicit answer: what happens when the user selects 23°C before the 22°C request finishes? The interface needs to distinguish the newer intention from the older result. Otherwise, an older failure can clear the newer pending state, or an older success can overwrite what the user just requested. This is a review risk to test, not a reported defect in AAOS.

Specify the message the user can trust

The integration contract should name the evidence that ends a pending indication and the evidence that updates the displayed target. Keep these decisions visible to the HMI, adapter and verification owners. A generic “success” flag leaves each team free to interpret a different event.

For this temperature example, my recommendation is to retain reported target state independently, track each outstanding intention, and resolve it using the request result and the property's documented semantics. Show actual temperature only when the system provides a valid measurement for the intended area. A successful setting should not masquerade as a completed heating operation.