Make AndroidAutoService extensible (open class) for custom HostValidator

[sbergmair]

Why

AndroidAutoService.createHostValidator() currently hardcodes HostValidator.ALLOW_ALL_HOSTS_VALIDATOR, which allows any app on the device to bind to the Android Auto CarAppService with no host validation. This is fine for development but is a security concern before a production release, since apps typically want to restrict which hosts (e.g. only the official Android Auto/Automotive OS apps) can connect.

Since AndroidAutoService and its overridden methods were implicitly final (Kotlin default), consuming apps had no way to customize this behavior without forking the plugin.

What changed

1. Make AndroidAutoService extensible

• class AndroidAutoService -> open class AndroidAutoService
• override fun createHostValidator() -> open override fun createHostValidator()

No default behavior changes — ALLOW_ALL_HOSTS_VALIDATOR remains the default. This just allows consumers to subclass and override host validation:

class MyAndroidAutoService : AndroidAutoService() {
    override fun createHostValidator() =
        HostValidator.Builder(applicationContext)
            .addAllowedHosts(R.array.hosts_allowlist)
            .build()
}

and register MyAndroidAutoService in their own AndroidManifest.xml instead of AndroidAutoService.

2. Expose androidx.car.app:app as an api dependency

• implementation("androidx.car.app:app:1.7.0") -> api("androidx.car.app:app:1.7.0")

Why this is good practice: Gradle's rule of thumb is to use api whenever a dependency's types appear in your library's public API surface, and implementation when it's purely an internal detail. Since AndroidAutoService is now open and directly exposes androidx.car.app types in overridable members:

• AndroidAutoService extends androidx.car.app.CarAppService
• createHostValidator() returns androidx.car.app.validation.HostValidator
• onCreateSession() returns androidx.car.app.Session

...any app that subclasses AndroidAutoService (e.g. to provide a custom HostValidator as shown above) must have these types on its own compile classpath. Before this change, consumers had to know to add androidx.car.app:app to their own build.gradle themselves, undocumented and only discoverable via a compile error. With api, the dependency is now transitively exposed, so it just works out of the box — the correct outcome for a dependency that's unavoidably part of the public contract, not a leaked implementation detail.

(One trade-off: consumers are now pinned to androidx.car.app:app:1.7.0 by default, though they can still override it with a newer version in their own build.gradle if needed, since Gradle resolves to the highest requested version.)