This library is the one place its consumer apps read and write a car. That makes it security-relevant even though it holds no credentials and opens no network.

Please do not open a public issue for a vulnerability. Use GitHub's private vulnerability reporting instead. Say what you were able to do, on which firmware generation, and whether the vehicle was moving.

• A road-behaviour write reaching the vehicle above 0 km/h, or on an unreadable speed (the gate must fail closed).
• A gated setter missing @RequiresStandstill, or the gate being bypassable.
• A catalogue entry that maps to a vehicle capability outside its declared @SupportedOn set, or a wrong property id that writes an unintended vehicle property.
• Deserialization of a crafted DrivingProfile/ProfileBackup causing unintended writes.

• The library declaring no permissions and no sharedUserId. Granting vehicle access is the consuming app's decision (platform signature / privileged install); report those choices against the app, not here.
• Climate/window reads returning null on a firmware that does not expose them — that is the unverified-and-read-only design.
• OEM firmware vulnerabilities — report to SAIC.

• The 0 km/h gate lives here, applied inside the low-level write primitives, so every consumer inherits it in one place. @RequiresStandstill documents each gated setter and a test asserts the set.
• No raw "write property 0xNNNN" API is exposed to consumers beyond the typed setters; the action catalogue is a closed vocabulary.
• Climate/window writes are intentionally absent. Reads are unverified; a write path waits on on-vehicle confirmation.
• Reflection targets are kept via consumer-rules.pro so R8 in a consumer app cannot strip the android.car/SAIC/model/catalogue names resolved by name at runtime.