Ich meine die Variante, zu der man Zugang über die Google Gruppe ganz am anfang dieses Posts erhält. Zumindest dein Name und eine der Adressen lässt darauf schließen. Die unterscheidet sich nochmal und wäre interessant zu sehen, wie die auf dem EX30 aussieht.
ich schreibe dir gleich noch mal eine PN mit einer Anleitung, wie du mir Logs zukommen lassen kannst. Da würde ich dann doch gerne mal rein schauen, wenn ABRP zugriff auf den Akku hat 
Nun, was soll ich sagen… Es gibt leider Mal wieder eher unerfreuliche Nachrichten. Seht am besten selbst:
Diese Regel gibt es erst seit Mai diesen Jahres und war mir schon vorher bekannt. Die Letzten Uploads in den Play Store wurden aber noch durchgewunken. Daher habe ich mir da keine all zu großen Gedanken gemacht.
Was das nun für den CSV bedeutet: Ich werde vorerst aus der „Play-Edition“ den Tripverlauf und das Legacy-Dashboard entfernen müssen, und anschließend eine alternative Umsetzung für das ganze zusammenschustern, eingepfercht in die Starren Beschränkungen des App Host.
So sehr ich viele der Vorgaben von Google verstehe, was Apps in Autos anbelangt, diese Regel finde ich völlig Banane. Mir erschließt sich nicht, warum man die User Experience „While Parked“ dermaßen beschneiden muss. Das hat dann ja auch alles nichts mehr mit Fahrerablenkung zu tun. Spiele darf man spielen, Filme gucken, im Web surfen. Aber eine nützliche App darf keine UI darstellen, die nicht mit Templates gebaut wurde, die eigentlich für die Bedienung während der Fahrt konzipiert wurden? Das entzieht sich bei mir jeglichem Verständnis.
Ich werde auf jeden Fall nach Wegen suchen, die möglichst keinen Einfluss auf die Funktionen der App haben. Aber das wird vermutlich nicht ganz einfach. Das macht mir leider etwas einen Strich durch die Rechnung, mich jetzt auf neue Features und die überarbeitung alter zu konzentrieren. Ich bin jetzt jedenfalls erst Mal bedient …
Das ganze betrifft nur die Alpha für die Play Store Edition. Die eh „illegale“ Version in den diversen internen Test Tracks bleibt davon unberührt, und der geplante Release von 0.27 für das kommende Wochenende dürfte davon nicht gefährdet sein.
So, es ist mal wieder soweit und ich muss etwas meinen Frust über Google raus lassen.
Bereits vor einigen Wochen gab es eine Änderung beim Car App Host, der das Debouncing beim Refreshen von Screens massiv erhöht hat (Ca. 8 bis 10 Sekunden statt ursprünglich 1 Sekunde).
Das hat sich bei der Play Edition vor allem dadurch bemerkbar gemacht, dass die „Echtzeit“-Daten sich nur noch alle 8 Sekunden aktualisiert haben. Das an sich ist ja schon schlimm genug. Aber es wird noch „besser“…
In meinem letzten Beitrag habe ich berichtet, dass Google es verbietet „Parked Experiences“ in IOT-Apps anzubieten, die nicht im App Host untergebracht sind. Entsprechend musste ich den Tripverlauf und das Legacy-Dashboard deaktivieren. Nun habe ich damit bekommen, zumindest den Tripverlauf halbwegs brauchbar per App Host zu implementieren. Dabei fällt das oben erwähnte Debouncing extrem negativ auf: In de Regel dauert das Laden der Trip-Liste von der lokalen Datenbank wenige Millisekunden. Entsprechend wären die Daten sehr schnell für den Nutzer verfügbar. Tja, mit diesem Debounce muss man nun beinahe 10 Sekunden laden, bevor irgendetwas passiert… Man schaut sich also solange einen Ladekringel an, obwohl die Daten schon lange da sind.
Zur Demonstration, der vergleich vom Laden der Trips im App Host vs. über meine eigene UI:
Ebenfalls davon betroffen ist z.B. EVMap: Wenn ihr dort die Filter bearbeiten wollt, dann dauert das auch fast 10 Sekunden, bis eure Filter erscheinen, auch wenn ihr nur einen einzigen angelegt habt und die Datenmenge verschwindend gering ist. Versucht das gerne mal selber bei euch im Auto. Johan hat dazu einen Issue bei Google eingereicht. Mal sehen, was daraus wird. Vielleicht bekommt das ganze ja mehr Aufmerksamkeit, wenn ihr dem Issue ein „+1“ gebt 
https://issuetracker.google.com/issues/358798731
Meine Vermutung ist, dass das ganze dazu dienen soll, den Fahrer weniger abzulenken. Aber wenn ihr mich fragt, bewirkt das ganze genau das Gegenteil. Wenn Ladezeiten dermaßen künstlich verlängert werden, und ich darauf warten muss, dass etwas zu sehen ist, lenkt das mental doch viel eher ab, als eine schnell reagierende App, die zu jeder Zeit relevante Daten anzeigt, und nicht erst nach einem Delay von 10 Sekunden, in dem ich immer wieder zum Display schauen, ob schon was da ist. Oder was denkt ihr?
Man wird als Entwickler schon in das wirklich enge Korsett dieses Car App Host gezwängt, und dann wird dessen Innenseite auch noch mit Reiszwecken gespickt, damit die User Experience für die Nutzer auf ein unterirdisches Niveau sinkt…
Da fehlen mir die Worte…
Ganz spontan, off topic von CSV und rein spekulativ, aber aus echtem Interesse gefragt:
Oder bringe ich da jetzt als völliger Laie in solchen Fragen der Datenverarbeitung zwei ganz verschiedene Dinge durcheinander? Danke für euer Schwarmwissen… 
Meinst du die App, die Iternio selber veröffentlicht, oder die von Polestar, die es schon seit ein paar Jahren gibt?
bei der „alten“ ABRP-App würde ich es eher auf mangelnde Optimierung schieben. Mit 5.0 ist das ja wesentlich besser geworden.
Das, was wir jetzt hier bei EVMap und CSV beobachten ist eine künstliche Verlangsamung des Car App Host. Über den „Refresh“-Button im CSV wird die „invalidate()“-Funktion manuell getriggert. Und dann sind die Daten auch augenblicklich sichtbar. Daher macht der App Host hier offensichtlich einen Unterschied zwischen „invalidate()“-Aufrufen, die aus Nutzereingaben stammen, und solchen, die von der App selbst ausgelöst werden (z.B. wenn Daten fertig geladen wurden).
Ich meinte die von Polestar veröffentlichte ABRP App, die es ja inzwischen auch in der Version 5.X gibt, und die tatsächlich seither nach der Eingabe weniger „Hänger“ hat. Danke für deine Einschätzung in Richtung „mangelnde Optimierung“.
Deshalb bitte nun auch wieder zurück zum Thema des Threads: Zukunft des CSV .
Siehe:
https://issuetracker.google.com/issues/305653634
Und ja… es ist einfach dumm, aus zweierlei Gründen:
a) es lenkt mich mehr ab. Ich drücke den Knopf, sehe das Ergebnis und bin zufrieden. Jetzt… wie du schon sagst… ich drücke den Knopf… Eieruhr. Ich schaue weiterhin drauf „kann ja nicht so lange dauern“, etc.
b) „Also demnächst kaufe ich lieber ein Fahrzeug OHNE AAOS… Android in den Autos kannst du einfach vergessen. Jeder Klick und du darfst erstmal 10 sec warten… da war ja selbst System XY von vor 10 Jahren besser!“
Status: Won’t Fix (Intended Behavior)
Hi folks, this is a safety feature that prevents apps from refreshing the screen so often as to cause user distraction while driving [1]. For most car manufacturers, this is a 10 second delay; however, the OEM has the option to override this to any value they deem appropriate[2]. It’s documented a bit hidden in the docs here: Plan task flows | Design for Driving | Google for Developers
The user always has the option to press the refresh button if one is provided which will allow for an unthrottled refresh.[3]
We’re open to revisiting about how this system works, but we thought it was better than a rolling window, or a complex heuristic model; both of which are harder for app developers to predict behavior.
Also, das ist eine spezielle Art von…speziell.
[1] Ich finde, das sollte auch für Navigations-Apps gelten. 
[2] Wir finden, dass 10 Sekunden ein toller Wert sind, der Hersteller kann da aber auch 100 Sekunden oder 0 Sekunden einstellen. Eigentlich haben wir keine Ahnung, aber wir haben mal was gemacht.
[3] Es lenkt definitiv weniger ab, auf das Display zu schauen, festzustellen, dass die Daten nicht angezeigt werden, den Knopf zum Refreshen auf dem Display zu suchen, den zu klicken und dann auf das Rendering der Daten zu warten.
Mir fehlten die Worte.
Jetzt fällt mir gar nichts mehr dazu ein.
Ja, die Antwort kenne ich natürlich, und habe in dem Issue auch dazu geschrieben, dass ich da was anderes vermute, einfach weil sich das Verhalten emulatorübergreifend verändert hat. Aber ausschließen, dass es das gleiche Thema ist, kann ich natürlich nicht. Zeitlich sind die Issues auch Recht weit auseinander und bei AAOS ist das erst ein frisches Thema.
Den Punkt werde ich auch auf jeden Fall bei meinem nächsten Gespräch mit Polestar ansprechen. Vielleicht können die ja zumindest für Polestarfahrer da was dran ändern
Und was echt traurig ist, was besonders die „Parked Experiences“ betrifft: Polestar kann sich theoretisch austoben, wie sie wollen, brauchen keinen App Host verwenden, aber liefern trotzdem den JL 2.0 mit wirklich rudimentärer UI ab, während externe Entwickler etwas mehr nützliche Daten Anzeigen wollen, es aber einfach nicht dürfen. Immerhin muss der JL keine 10 Sekunden warten.
Ich zitiere Mal Martin: „Das ist völlig gaga“
Das Android Automotive Ecosystem (mit Google Apps / GAS) ist halt leider echt komplett tot.
Es wären viele coole Dinge möglich, aber mir den Beschränkungen entwickelt sich null.
Man braucht ja nur mal in den Store schauen: der ist toter als tot und 50 % der Apps sind wie aus einem schlechten Traum (super exotische Nischenapps, unbrauchbare UIs)
Eigentlich hat man Stand heute als Anwender sehr wenig davon, dass Android Automotive Verwendung findet.
Man könnte sogar sagen, dass man im Vergleich zu Hersteller-Systemen mit Android Auto im Nachteil ist.
Auf 5 Jahre alten Autos kann man sich problemlos WhatsApp-Nachrichten vorlesen lassen, das träumt man bei Android Automotive is immer noch von.
Split Screen gibt’s auch nicht, man fuchtelt also doch wieder aufm Screen rum und ist abgelenkt (die Tiles sind ein guter Start, aber die angezeigten Daten nicht immer ausreichend und manche Apps zeigen gar nix.)
OK, man kann die Klima mit Sprachbedienung etc regeln, aber im Grunde sind das eine Handvoll Befehle und besonders tolerant bezüglich der Syntax ist die auch nicht. Besser als in anderen Autos, aber wiegt den Rest imho nicht auf.
Mein Fazit bisher: als Anwender bringt es mir sehr wenig und sogar handfeste Nachteile.
Die Motivation war wohl eher auf Herstellerseite, um sich die Basisarbeit für eigene Entwicklung zu sparen.
Tot würde ich jetzt nicht sagen. AAOS eröffnet schon einige Möglichkeiten, die man auf anderen Systemen nicht hat, und ich denke auch, dass es gegenüber AA das überlegene Konzept ist.
Ich sehe da eher ein Problem bei Google, die zu langsam reagieren, was das ganze für den Nutzer unverständlich macht. Dazu kommen andere Faktoren wie nicht nachvollziehbare Guidelines. Dass es solche Guidelines überhaupt gibt, finde ich grundsätzlich gut und richtig. Nur sind sie leider zum Teil schon sehr einschränkend. Dass es mehrere Jahre gendauert hat, um Messenger-Apps zu erlauben, ist schon traurig und war bisher ein sehr großer fehlender Baustein.
Das kann man aus zwei Richtungen betrachten: Android ist ein weit verbreitetes System, für das es wirklich viele Entwickler gibt. Das macht es für OEMs (theoretisch) wesentlich einfacher, qualifizierte Entwickler zu finden und qualitativ hochwertige Apps für die eigenen Autos zu entwickeln. Das macht es für mich umso weniger nachvollziehbar, warum z.B. der Journey Log davon quasi keinerlei Gebraucht macht. Wie andere OEMs mit sowas umgehen, kann ich bisher nicht beurteilen.
Ich denke, das System AAOS wird schon eine Zukunft haben. Mit BMW und Audi wird das System ja auch auf Autos ohne Google Built-In verwendet. Auch da können Apps von dritten (z.B. EVMap) installiert werden. Mit deren Guidelines habe ich mich bisher nicht auseinandergesetzt, aber vermutlich sind die Prozesse dort auch andere als beim Giganten Google.
Bei Google fehlt aktuell einfach etwas die Freiheit, sich als Entwickler austoben zu können. Ich hätte aber auch keine bessere Antwort darauf, wie man Grundlegende Sicherheitsanforderungen durchsetzen soll, ohne sowas wie den Template Host zu verwenden. Irgendwo ist Google ja schon dafür verantwortlich, was auf dem Play Store verfügbar ist, und umfassende Beurteilungen jeder einzelnen App ist allein personell vermutlich kaum zu bewerkstelligen.
Ein Kuratoren-Programm für „Sonderfälle“ wäre schön, aber ich fürchte, sowas ist eher Wunschdenken.
„Komplett tot“ ist sicher übertrieben gewiesen, ja.
Bin auch absolut bei dir, es braucht eine konsistente Policy und Design Guidelines. Es wird sonst Kraut und Rüben.
Aktuell ist es halt unbefriedigend - wenn nach mehreren Jahren keiner Apps schreibt und Verbesserungen / Fixes nur tröpfeln, dann läuft etwas schief.
Die Qualität der Apps wie Journey Log ist halt auch unterirdisch, und sie haben es ja geschafft es nochmal unterirdischer zu machen
Und engagierte Entwicklern, wie beim Stats Viewer, macht man es ja praktisch unmöglich, etwas von Wert zu schaffen. Das ist ja im der aktuellen Version so zurechtgestutzt, das er eigentlich bis auf die API Anbindung für die Katz ist… keine Diagramme, unbrauchbare refresh time…
So, ein kleines Update, wie es in Zukunft weiter geht:
Thema Veröffentlichung für Alle:
Wie ich schon erwähnt hatte, ist der Funktionsumfang der App derzeit durch die Einschränkungen durch den Car App Host deutlich eingeschränkt. Ich bemühe mich nach wie vor darum, dass ich daraus das beste mache, um auch möglichst wenige Funktionen verzichten zu müssen. Allerdings bin ich selber nicht wirklich zufrieden damit, was mit dem App Host derzeit möglich ist. Echtzeitdaten sind eine Sache, aber dass so Dinge wie interaktive Diagramme, die ohnehin nur im geparkten Zustand verfügbar sein sollen, damit nicht umsetzbar sind, stört mich aktuell schon sehr.
Ich werde demnächst wieder die Gelegenheit haben, mich etwas ausgiebiger mit meinen Kontakten bei Polestar auszutauschen, und dieser Umstand steht weit Oben auf meiner Agenda. Ich kann derzeit leider nicht im entferntesten abschätzen, ob dabei irgendetwas herum kommt, und hoffe selber auf das beste …
Aber es gibt auch ein paar schönere Themen, die ich ansprechen möchte:
Für das nächste Update habe ich mir vorgenommen, die UI der App grundlegend zu überarbeiten und damit vor allem auch für andere Modelle (auch von anderen Marken) fit zu machen und weniger auf den P2 auf Maß zuzuschneiden.
Dabei nutze ich die Gelegenheit, alten Layouts einen neuen Look zu verpassen und ansprechender zu gestalten. Angefangen habe ich dabei beim Einstellungsmenü. Die Änderungen sind nicht super spannend, aber zuletzt empfand ich die Struktur der Einstellungen als etwas wahllos zusammengewürfelt, weil immer mal wieder neue Kleinigkeiten dazu gekommen sind.
Wesentlich spannender dürfte da mein Konzept für die überarbeiteten Trip-Details sein Hier mal WIP-Screenshots aus meinem Dev-Build (einiges ist noch Platzhalter/ohne Funktion/nicht übersetzt, es geht erst mal nur um das Konzept):
Ich denke, die größte Änderung fällt euch direkt ins Auge
Die Karte soll dann in Zukunft noch weitere Informationen enthalten und entsprechend interaktiv sein, z.B. mit Markierungen für Ladestopps etc. Schon jetzt ist es eine dynamische Karte, die man nach belieben zoomen und verschieben kann. Also kein Statisches Bild wie zuvor beim alten Journey (RIP an der Stelle )
Auf Displays wie im Polestar 4 kann das dann z.B. so aussehen 
An dieser Stelle hätte ich gerne mal euer Feedback für vertikale Displays (also wie im Polestar 2): Welche Daten wären euch auf den ersten Blick am wichtigsten? Würdet ihr die Umsetzung wie aktuell in den Screenshots zu sehen, bevorzugen (Also die Karte großflächig in einem eigenen Tab), oder würde euch eine etwas kleinere Karte (an der Stelle, wo aktuell das Diagramm ist) zusammen mit den wichtigsten Daten besser gefallen, bei der man dann die übrigen Details und das Diagramm „ausklappen“ kann? z.B. dann so, als grobes Paint-Mockup:
Kanal & Gruppe
Chatten.
Für Small Talk nutzen wir den Telegram-Messenger.
Hier kannst du unserer Gruppe beitreten:
Offizielle Website
Informieren.
Community
Diskutieren.
