Breeze 2.2.1
The Android Auto surface now actually appears in the car. It never did before — on a phone with Auto's developer mode and unknown sources enabled, Breeze was simply absent from the launcher, with nothing in any log to say why.
The fix
BreezeCarAppService declared its two categories (IOT and POI) as two separate <intent-filter> blocks. That resolves correctly in PackageManager — both category queries returned the service, which is why it looked healthy from every angle — but Auto's host reads the categories off the first ResolveInfo it gets, saw only IOT, and dropped the app before it ever reached the launcher. One filter carrying both categories (the shape SmartThings uses, which does appear) and Auto picked it up immediately.
Verified end to end against the Desktop Head Unit on Auto 17.3.662854:
GH.AppNotifier: Posting notification for new app ComponentInfo{app.breeze.breeze/…BreezeCarAppService}
BreezeCar: CarAppService created
BreezeCar: onCreateSession — host connected
BreezeCar: onCreateScreen — building PowerScreen
BreezeCar: onGetTemplate — paired=true units=3
Also in this release
- Host validation relaxed for release builds. The old allowlist path was right for a Play app and wrong for a sideloaded one: the Desktop Head Unit isn't a signed host, so it made the car surface untestable, and any mismatch failed silently. What a rogue host can do here is toggle an air conditioner.
- The car classes now log.
onCreate→onCreateSession→onCreateScreen→onGetTemplateunder tagBreezeCar. Previously "the host bound us and we threw" and "the host never bound us" produced identical logcat output, which is most of why this took so long to find. - The About dialog no longer lies about the version. It was a string literal, so it still read 2.2.0 in a 2.2.1 build; it's now read from the installed package, and Diagnostics reports the app's version alongside the server's.
Requires a Breeze Core server on your network. Also available from the package host: https://bolero.salataputarica.hr.eu.org/android/