The one place a service badge is worth reading is the car it belongs to, and
that is the one place the app could not be opened: Android Auto runs no Flutter
engine, so a Flutter app is simply absent from the head unit. The same APK now
carries a second face — Car App Library templates the host draws itself, in
Kotlin under android/app/src/main/kotlin/com/drivervault/phoneapp/car/.
Two screens. The garage lists a car per row with its due badge on the second
line, worst first, because the host renders only the first handful of rows and
the car this list exists to mention is the overdue one rather than whichever was
added first. A tap opens what that car has coming: the odometer, the next
service, and the reminders the server holds for it — typed in and auto-derived
from documents and the service schedule alike, in the order it sorted them.
None of it is a second implementation of the app. VaultStore reads the session
the phone signed in with — the active server's base and token — out of
shared_preferences' own store, which both halves share, so a server switched on
the phone is the server the car reads from with nothing to keep in step; only
cc_active_base is new, because an untouched home entry carries no address of its
own, its base being kDefaultApiBase, a compile-time define nothing outside Dart
can see. CarStrings reads the same assets/i18n files by the same dot paths, so a
badge on the head unit is the string format.dart already puts on the phone, in
the language the account chose: of the 32 keys the car screens ask for, 28 are
keys a phone screen already used, and only carApp.* is theirs. CarFormat is
format.dart's twin — same date pattern and number grouping from the account's
settings, same worst-of-date-and-km service badge. A new test reads the Kotlin
for the keys it looks up and fails if any is missing from a language file, since
the analyzer's reach stops at the Dart.
It only reads. A screen you cannot type into is a poor place to edit a car and a
driver is a poor person to ask, so VaultApi has no write in it to reach for by
accident.
Three things the README now says out loud. The service is declared IOT, the
closest category the library defines for something that is a garage rather than
a map or a media player, which matters to a store submission and not to a
sideload. The app lock does not reach the head unit: the flag is in memory and
the credentials behind it in encrypted storage, neither readable from the car
service, and there is no fingerprint reader in a dashboard to satisfy it with.
And the home charger is not on there — the chargers endpoint relays its plugin's
payload verbatim with no shape to read, and the serial the control card is
driven by is never persisted, so the car would have nothing to name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Raises the adaptive-icon foreground inset from 16% to 25%, so the mark
occupies 54 of the 108dp canvas — well inside the 66dp safe zone — and
reads smaller against the launcher background.
Affects API 26+ only. minSdk is 24, so Android 7.0/7.1 still falls back
to the unchanged legacy mipmap rasters.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Updates the Gradle namespace/applicationId, moves MainActivity.kt to the
matching source directory, and refreshes the package id in the README.
The Dart package name in pubspec.yaml is unchanged. Since the application
id changed, existing installs will not upgrade in place and their local
secure-storage/prefs data does not carry over.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Flutter only adds android.permission.INTERNET to the debug and profile
manifests, so release APKs shipped with no network access at all — the app
could not reach the API Server. Declaring it in the main manifest fixes
release/production builds; debug was unaffected because its own manifest
already granted it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
