AutoNavAlerts, Teil eins: ein eigenes Navi für Android Auto

Googles Karte, meine Blitzer, eine App

Ich wollte eine Sache auf dem Autobildschirm. Googles Karte, Googles Verkehrslage und Googles Abbiegehinweise, mit meinen eigenen Blitzerdaten obendrauf, und Warnungen nur für Blitzer, die tatsächlich auf meine Straßenseite zeigen.

Ich habe nichts für Android Auto gefunden, das das kann. Google Maps hat die Karte und das Routing, aber man kann keine eigene Blitzerdatenbank hineinladen. Also baue ich es selbst.

Es heißt AutoNavAlerts. Es ist eine Navigations-App für Android Auto auf Basis von Googles Navigation SDK, mit einem Warnsystem für Blitzer und Points of Interest obendrauf. Die erste Blitzerquelle ist PocketGPSWorld, mit meinem eigenen bezahlten Abo. Der Code ist öffentlich, unter der Apache License 2.0¹, auf github.com/damo2929/AutoNavAlerts.

Das ist Teil eins einer Serie. Er behandelt, was die App kann, was Google einer Drittanbieter-App auf einem Autobildschirm erlaubt und was nicht, und wie sie gebaut wurde, denn fast jede Zeile wurde von Claude geschrieben, dem KI-Modell von Anthropic. Ich habe die Regeln gesetzt, getestet und stehe für das Ergebnis gerade. Dieser letzte Teil ist eine Geschichte für sich.

Es ist Version 0.1.0. Sie ist per Sideload installiert, nicht im Play Store, und hatte eine echte Fahrt. Lies es als Baulog, nicht als Produktvorstellung.

Was es heute kann

Das steckt im Testbuild, und dafür ist jeder Teil da:

Die Blitzerwarnungen sind der Grund, warum es die App gibt, also bekommen sie den nächsten Abschnitt.

Ein Blitzer zählt nur, wenn er auf dich zeigt

Eine Blitzerwarnung, die für die Gegenfahrbahn auslöst, ist schlimmer als gar keine. Sie bringt dir bei, die Warnung zu ignorieren. Deshalb ist die erste harte Regel im Design, dass ein Blitzer nur warnt, wenn er in deine Fahrtrichtung zeigt, und diese Regel wird nie gelockert, nie per Voreinstellung umgangen und nie fallen gelassen, wenn die Daten unbequem sind.

Die Logik läuft bei jeder Positionsbestimmung, bis zu zehnmal pro Sekunde. Für jeden Blitzer in der Nähe stellt sie vier Fragen, in dieser Reihenfolge:

Die 45° sind nicht großzügig. Die TomTom-Dateien von PocketGPSWorld geben die Richtung eines Blitzers in acht Himmelsrichtungen an, also gehen 22,5° davon an die Daten, bevor irgendetwas anderes passiert. Eine GPS-Richtung kostet ein paar Grad mehr, und die Krümmung der Straße noch ein paar. Deshalb darf nichts anderes daran knabbern.

Ein Blitzer, der die Richtungsprüfung nicht besteht, wird trotzdem auf der Karte gezeichnet, abgeblendet, mit einem Pfeil, der zeigt, wohin er schaut. Du kannst ihn sehen. Er redet nur nicht mit dir.

Die Stufen sind zeitbasiert, keine festen Entfernungen. Die erste Warnung kommt 15 Sekunden vorher bei deiner aktuellen Geschwindigkeit, die zweite bei der Hälfte davon, beide mit einer Untergrenze, damit sie der dritten nie zu nahe kommen. Die dritte liegt fest bei 100 Yards und ist Pflicht, solange der Ton an ist. Die Auslösedistanz wächst während einer Annäherung nur, also verkürzt starkes Bremsen nicht die Warnung, die dir schon zustand.

Was Google einer App auf dem Autobildschirm erlaubt

Hier wird es interessant, denn eine Drittanbieter-App auf Android Auto ist nicht Google Maps. Sie läuft innerhalb der Regeln der Car App Library von Android Auto, die Apps „a set of visual templates approved for driver safety“² gibt, und innerhalb dessen, was das Navigation SDK freigibt.

Drei Lücken haben die App mehr geprägt als alles, was ich selbst bauen wollte:

Nimm das Tempolimit. Google kennt es. Google sagt einer App, wie weit du drüber bist, als Prozentsatz und Schweregrad, und gar nichts, solange du drunter bist. Darf ich fragen, warum ein Fahrer das Limit erst erfahren darf, wenn er es schon überschreitet? Darauf werde ich keine Antwort bekommen, also umgeht die App es. Solange du drüber bist, rechnet sie das Limit aus deiner Geschwindigkeit und dem Prozentsatz zurück. Darunter nimmt sie den Blitzer, auf den du zufährst, dann den OpenStreetMap-Download, und sie zeigt einen Strich statt gar nichts, wenn sie überhaupt kein Limit hat.

Störungsmeldungen haben dieselbe Form. Die Melde-APIs gibt es in der Navigationsansicht auf dem Handy, aber nicht in der im Auto. Jemand hat Google schon darum gebeten⁵, und die Anfrage ist noch offen. Die App prüft zur Laufzeit, ob es die APIs gibt, also erscheint Googles Melde-Knopf ohne Änderung an meinem Code, falls ein späteres SDK sie nachliefert. Ein GitHub-Actions-Job prüft das jedes Quartal und eröffnet ein Issue an dem Tag, an dem es passiert.

Die Touch-Regel hat mich richtig erwischt. Die Autokarte des SDK zeichnet ihre eigene Ankunftskarte, Kopfzeile, Zentrieren-Knopf, Tacho und Fahrtleiste. Keins davon nimmt einen Tipp an, weil keine Berührung die Ansicht des SDK erreicht. Sie sehen aus wie Knöpfe und tun gar nichts. Also sind sie alle abgeschaltet, und die App zeichnet ihre eigenen Bedienelemente dort, wo ein Tipp tatsächlich ankommt.

Bring deinen eigenen Schlüssel mit, bring deine eigenen Daten mit

Zwei Entscheidungen halten diese App ehrlich in Sachen Geld und Lizenzen, und beide sind Absicht.

Es gibt keinen eingebauten Maps-Schlüssel. Die Google Maps Platform braucht „a billing-enabled Cloud project“⁶, und das Navigation SDK braucht ein Projekt, in dem es aktiviert ist⁷. Würde ich einen Schlüssel mitliefern, würde das Fahren aller Nutzer mir in Rechnung gestellt, oder der Schlüssel würde durchsickern und mir trotzdem in Rechnung gestellt. Also bringt jeder Nutzer seinen eigenen Schlüssel mit, in seinem eigenen Google-Cloud-Konto. Die Handy-App kann einen mit deinem eigenen Google-Konto anlegen, oder du fügst einen ein. Er wird verschlüsselt auf dem Handy gespeichert. Es gibt keinerlei Rückfallebene, und die App macht keinen einzigen SDK-Aufruf, bevor dein Schlüssel drin ist.

Es gibt keine Blitzerdaten in der App. PocketGPSWorld lizenziert seine Datenbank zur persönlichen Nutzung, versieht jeden Download mit einem Wasserzeichen für das Mitglied und verbietet, sie irgendwo abzulegen, wo jemand anderes als der Käufer drankommt. Also liefert die App sie nie mit, hostet sie nie und synchronisiert sie nie zwischen Handys. Du meldest dich mit deinem eigenen Abo an, und das Handy lädt deine eigene, mit Wasserzeichen versehene Kopie in privaten Speicher, der von Backups ausgenommen ist. Auf dem Prüfstand waren das 19.826 Blitzer in 33 Sätzen, ein Satz pro Datei, nie zusammengeführt.

Die automatische Synchronisierung ist höflich dabei. Sie liest einmal am Tag den öffentlichen RSS-Feed von PocketGPSWorld⁸ und meldet sich nur an, wenn es eine neue Veröffentlichung gibt. Sie tauscht die Blitzer nie aus, während du navigierst.

Eine Klausel in deren Lizenz ist damit nicht ganz geklärt, die über das Einbinden der Daten in eine Anwendung. Für meinen eigenen Gebrauch nehme ich das hin. Bevor die App an irgendjemand anderen geht, bekommt PocketGPSWorld eine E-Mail mit der Frage.

Zwei Tage, 87 Commits, und zuerst ein Designdokument

Jetzt der Teil, über den die Leute streiten werden. Ich habe diesen Code nicht getippt. Claude hat es getan, über Claude Code, mit zwei Modellen, Claude Fable und Claude Opus. Ich habe die Anforderungen geschrieben, jede Entscheidung getroffen, den Prüfstand betrieben, das Auto gefahren und geprüft, was zurückkam. Jeder Commit mit KI-geschriebenen Änderungen trägt einen Trailer, der das sagt, und die README auch.

Das sind die Zahlen, direkt aus dem Repository abgelesen:

Das Designdokument kam zuerst, und das ist das Nützlichste, was ich jedem sagen kann, der so etwas macht. Seine erste Zeile sagt, dass kein Code geschrieben wird, bevor es abgenommen ist, und dass jede spätere Änderung zuerst dort gemacht wird. Jede Klasse hat eine aufgeschriebene Aufgabe. Jeder Schwellenwert hat einen Grund. Jede Regel, die ich gesetzt habe, ist als meine markiert, mit Datum.

Das zählt, weil ein Modell vergisst. Eine lange Sitzung wird zusammengefasst, und die Zusammenfassung behält das Wesentliche und lässt die Details weg, und in den Details stecken die Fehler. Die eigene AGENTS.md des Repositorys sagt es klar: Verlass dich nicht auf eine Zusammenfassung dieser Dateien aus dem Gedächtnis oder aus einer früheren Sitzung. Der Agent geht zurück zum Dokument. Jedes Mal.

In der zweiten Phase arbeiteten außerdem zwei Agenten parallel, einer an Zielführung, Karte und Bildschirmen, der andere an Ortung, Warnungen, Sprache und Kartenmarkierungen. Jeder besaß eine schriftliche Liste von Dateien, und die Schnittstellen zwischen ihnen waren vorab festgelegt: hinzufügen, nicht umbenennen. Sie ließen sich sauber zusammenführen, weil die Grenze gezogen war, bevor einer von beiden anfing, und nicht erst hinterher entdeckt wurde.

Jede harte Regel kam von etwas, das ich gesehen habe

Das Design hat eine Liste harter Regeln, und keine davon kam von einem Whiteboard. Jede kam daher, dass ich das Ding auf der Desktop Head Unit⁹, Googles Autobildschirm-Emulator auf dem PC, oder im Auto habe laufen sehen und es etwas falsch gemacht hat.

Das Wackeln ist mein Liebling, weil es so klein ist und es ausgeliefert worden wäre. Eine Live-GPS-Zeile tickte einmal pro Sekunde. Jeder Tick schickte den ganzen Bildschirm neu, unverändert, und der Host animierte ihn, also zitterte jede Zeile darunter, während das Auto stillstand. Der Fix ist ein einziger Vergleich: nur neu zeichnen, wenn sich eine Zeile geändert hat. Die Regel ist größer als der Fix. Ein Bildschirm, der stillhält, muss auch still aussehen, und das wird mit einer Serie von Screenshots geprüft, die identisch sein müssen.

Das ist die eigentliche Arbeit, wenn eine KI den Code schreibt. Sie wird nicht müde und hat nichts gegen Umschreiben, aber sie kann den Autobildschirm nicht sehen. Du schon. Was du gesehen hast, als Regel aufzuschreiben, mit Datum, verhindert, dass es drei Sitzungen später zurückkommt.

Was der Code falsch gemacht hat, und wie es gefunden wurde

Reichlich. Nichts davon war exotisch, und jeder Fehler wurde gefunden, indem es lief, nicht indem man es las:

Beim zweiten lohnt sich eine Pause. Jeder einzelne Test war grün. Der Code war nach seinem eigenen Maßstab korrekt. Er hatte nur einen Timeout, gewählt von jemandem, der nie ein Handy eine Entfernung laut vorlesen gehört hat. Der Test, der das findet, ist eine echte Stimme, mit Zeitmessung, auf einer echten Fahrt.

Die erste echte Fahrt

Am 12. Oktober habe ich einen Release-Build aufs Handy gespielt und ihn im XPENG G6 über kabelloses Android Auto ausgefahren. Zwei Dinge gingen schief. Eine im Stand gesetzte Route löschte sich innerhalb von Sekunden nach dem Losfahren. Und manche Warnungen wurden angesagt und manche nicht, ohne ein Muster, das ich erkennen konnte.

Dann das schlimmere Problem. Es gab nichts mehr zu lesen. Das ColorOS auf meinem Handy wirft die Logzeilen der App weg, also hinterließ die Fahrt überhaupt keine Beweise. War es die App, Googles SDK oder Android Auto selbst? Ich konnte es nicht sagen.

Also war die Lösung für die erste Fahrt keine Codeänderung. Es waren Beweise. Die App schreibt jetzt ständig zwei Logs auf dem Handy, eins für Routing und Karte und eins für jede Warnungsentscheidung, in 15-Sekunden-Paketen, dazu einen optionalen Fahrtenschreiber, der jede Position speichert, damit sich eine Fahrt auf dem Prüfstand nachspielen lässt. Dann wurden die Vermutungen behoben, jede so geschrieben, dass sie weniger tut und protokolliert, dass sie es getan hat. Jeder Weg, auf dem die Zielführung enden kann, hält jetzt fest, wer sie beendet hat.

Auf dem Prüfstand hat Android Auto seitdem einmal Stopp ausgelöst, 2 Minuten 35 Sekunden in eine geführte Fahrt hinein. Ich habe zu dem Zeitpunkt auf der Head Unit herumgeklickt, also war es höchstwahrscheinlich das X auf seiner eigenen Karte. Ohne dass jemand den Bildschirm berührt, ist es nicht passiert. Die nächste Fahrt wird es klären, denn diesmal hinterlässt die Fahrt eine Spur.

Wie es weitergeht

Die Liste für den Prüfstand ist noch lang. Die nächsten Fahrten prüfen den Abbrechen-Knopf, die Szenarien für Kurven und falsche Richtung, die Übergabe zwischen dem GPS des Autos und dem des Handys, und ob das Fahrerdisplay im G6 überhaupt Abbiegekarten von einer Drittanbieter-App anzeigt.

Spätere Teile dieser Serie gehen richtig auf die Mathematik der Warnlogik ein, die Umgehungen beim Tempolimit, die PocketGPSWorld-Formate und den Prüfstand selbst: wie man eine Android-Auto-App ohne Auto testet, mit einem geskripteten GPS und einem Emulator, der glaubt, jede Straße führe nach Norden.

Die Maschine tippt, der Maßstab ist deiner

Ich habe viel Gerede über KI, die Code schreibt, mitbekommen, das meiste von Leuten, die sie verkaufen, oder von Leuten, die Angst davor haben. Was ich gefunden habe, ist langweiliger als beides, und nützlicher.

Sie tippt schnell und langweilt sich nicht. Sie schreibt einen Bildschirm zum vierten Mal um, ohne zu seufzen. Was sie nicht tut, ist bemerken, dass der Mehr-Bildschirm wackelt, oder dass ein Satz abgeschnitten wurde, oder dass ein toter Knopf neben einem lebendigen sitzt. Sie kann das Auto nicht sehen. Das zu sehen war meine Sache, und der einzige Grund, warum es behoben ist, ist, dass ich jedes davon als Regel aufgeschrieben habe, die sie lesen muss, bevor sie irgendetwas anfasst.

Insofern wandert die Verantwortung nicht. Der Code ist meiner, weil ich den Maßstab setze, an dem er gemessen wird, und weil ich derjenige im Auto bin. Nichts von dem, was ihn ehrlich gehalten hat, ist eine KI-Methode. Die Spezifikation vor dem Code schreiben, aufschreiben, was man lernt, und Beweise sichern statt zu raten, so wurde ordentliche Ingenieursarbeit schon immer gemacht. Das Werkzeug ändert daran nichts. Es macht nur schneller sichtbar, wer es übersprungen hat.