Danke fürs aufnehmen in die Gruppe, wird am Wochenende mal getestet 
Passt schon 
Du bist ja immerhin einsichtig. Da gibt/gab es auch ganz andere Kandidaten hier 
Dass dir die neue Hauptansicht nicht gefällt ist ja auch durchaus nachvollziehbar. Aber um einen Kompromiss kommt man eben nicht herum. Und wie überall gilt bei Feedback und Kritik: Der Ton macht die Musik.
2 „Gefällt mir“
Videoaufnahme vom Maxi gefunden… wie er abermals mit dem Update des CSV konfrontiert wurde:
1 „Gefällt mir“
Hallo zusammen,
heute gibt’s leider erst mal schlechte Nachrichten, auch wenn diese nicht direkt den CSV betreffen, sondern mich als Google Play Entwickler im Allgemeinen.
Folgender Ausgangspunkt: Google hat neue Richtlinien eingeführt, wie sich Entwickler identifizieren müssen. Das Entwicklerkonto wird dafür mit Google Payments verknüpft und dort bestätigt man seine Identität. Soweit so unspektakulär.
Nun habe ich am vergangenen Wochenende den Verifikationsprozess gestartet und mir nichts Böses dabei gedacht. In der Play Console habe ich also mein Zahlungsprofil ausgewählt. Dabei ist mir aufgefallen, dass dort der Straßenname meiner Adresse abgekürzt ist, was nicht der offiziellen Bezeichnung auf meinem Perso entspricht. Bevor ich also bei Google Payments die Identifikation durchgeführt habe (Der Ball wurde dabei schon von der Play Console zu Google Payments geworfen…), habe ich sichergestellt, dass ich die Primäre Meldeadresse bei Google Payments korrigiere. Sah soweit auch gut und richtig aus. Also die Identifizierung gestartet und alle notwendigen Dokumente hochgeladen.
Und was passiert: Die zuvor korrigierte Adresse bei Google Payments wurde durch die vorherige, falsche Adresse ersetzt 
Resultat war natürlich, dass die Identifizierung fehlgeschlagen ist, und ich es noch einmal versuchen musste. Erst mal nahm ich an, dass ich vielleicht irgendwo den falschen Knopf erwischt habe, und die Adresse nicht richtig gespeichert wurde.
Also das ganze von vorn: Adresse in den Google Payments Einstellungen geändert, und dieses mal alle anderen Adressen aus dem Profil gelöscht. Nur noch die eine, als Meldeadresse markierte und 100% korrekte Adresse war im Profil vorhanden. Sogleich die Identifizierung erneut gestartet. Resultat: Die falsche, abgekürzte Adresse ist SCHON WIEDER zum Profil hinzugefügt worden und als Meldeadresse aufgeführt. Damit wird die Identifizierung mit Sicherheit erneut fehlschlagen.
Ich habe natürlich direkt den Google Payments Support kontaktiert. Allerdings können die mir auch nicht helfen. Ich möge den Google Play Console Support kontaktieren. Dessen Geschäftszeiten sind natürlich auf die Tageszeiten in Amerika beschränkt…
Ich habe grade eine Krawatte bis zum Südpol kann ich euch sagen …
Da ich die Befürchtung habe, dass diese Problem nachhaltig mein Entwicklerkonto verhunzt hat, hat das auch schwerwiegende Folgen für die Apps, die ich bisher veröffentlicht habe:
Zum Glück habe ich bisher keine öffentlichen Apps. Das heißt, wenn ich ein neues Entwicklerprofil erstellen muss, bin ich in der Lage, alle Nutzer meiner Apps zu kontaktieren und auf das neue Profil umzuziehen. Damit bleibt der Schaden für die Nutzerbasis überschaubar. Allerdings wird das dann für mich ein durchaus erheblicher Aufwand.
Daher hier mein dringlicher Aufruf an alle, die selber die Play Console nutzen, um z.B. einen Track des CSV bereit zu stellen: Achtet unbedingt darauf, dass eure Adressdaten EXAKT mit dem übereinstimmen, was auf eurem Personalausweis steht, BEVOR ihr in der Play Console den Verifizierungsprozess in Gang setzt! Ein nachträgliche Änderung ist anscheinend nicht möglich, und euer Entwicklerkonto ist anscheinend nachhaltig verloren…
Ich habe aktuell noch ein offenes Ticket beim englischsprachigen Support. Aber ich habe ernsthafte Zweifel, dass das Problem gelöst werden kann. Und ich weiß auch nicht, wie viele Versuche man zur Identifikation hat, bevor das Google Payments Profil dauerhaft gesperrt wird. Welche Folgen daraus dann resultieren kann ich aktuell auch noch nicht abschätzen…
Falls es hier irgendjemanden gibt (vielleicht @MoleMan oder @johan ?) , der schon mal ähnliches erlebt hat (Ich bin ja nach wie vor eher unerfahren, was das Veröffentlichen von Apps betrifft), ich wäre für jeden Hinweis und jede Hilfe dankbar. Ansonsten soll mein dummer Fehler eine Warnung an alle anderen sein, nicht über dieses sperrige System von Google zu stolpern.
Ich halte euch auf dem Laufenden, wie das ganze ausgehen wird…
11 „Gefällt mir“
Wie sagt man so schön? Unverhofft kommt oft 
Los gings schon heute früh um kurz vor 8. Da kam eine Antwort vom Play-Console-Support. Sinngemäß lautete die: „Wir sind nicht zuständig. Wenden Sie sich an den Payments-Support.“ Haha, Scherzkeks. Der Payments-Support hat mich doch grade zu euch geschickt! Da war ich direkt am frühen morgen erst mal ordentlich bedient…
Ich habe direkt danach aber erst mal nichts unternommen und abgewartet. Vor 20 Minuten kam dann eine weitere Antwort vom Support. Dieses mal von einem anderen Mitarbeiter. Die Antwort fiel überraschend umfangreich aus, und der Mitarbeiter hat sich meinen Fall offensichtlich länger als 30 Sekunden angesehen und nicht nur eine Mail zusammen kopiert.
Der Inhalt war zwar nicht wirklich auf das bezogen, was ich geschrieben habe, aber ich würde mal vermuten, dass zumindest gelesen und registriert wurde, was ich geschrieben habe.
Keine 10 Minuten Später kam dann eine Mail vom Verifikationsprozess, mit einer positiven Bestätigung meiner Identität 
Ich will nicht ausschließen, dass aufgrund meiner Schilderung sich jemand meine Angaben und Dokumente noch mal separat angesehen hat und manuell das Knöpfchen gedrückt hat. Wissen tue ich das aber natürlich nicht.
Die vielen Bedenken aus meinem vorherigen Post können also (in meinem Fall) vergessen werden, und ich kann mit meinem Entwicklerkonto weiter machen wie gewohnt
Dennoch möchte ich weiterhin darauf hinweisen, den Verifikationsprozess nicht auf die leichte Schulter zu nehmen, wenn ihr selber davon betroffen seid. Hier mal die Mail, die beim ersten Mal bei der Ablehnung kam:
Deine Identität konnte aus folgenden Gründen nicht bestätigt werden:
- Amtlicher Lichtbildausweis: Ein Teil des Dokuments war nicht sichtbar. Bitte achte darauf, dass alle vier Ecken des Dokuments sichtbar und Textpassagen, Unterschriften oder Bilder nicht verdeckt sind.
- Adressnachweis: Die Informationen im Dokument stimmen nicht mit den im Profil gespeicherten Informationen überein.
Der erste Punkt ist soweit unkritisch. Ich kannte es von anderen Identifikationsprozessen, dass man Daten auf dem Perso schwärzen kann, wenn diese nicht zwingend für die Identifikation erforderlich sind. Bei Google Payments ist das offenbar nicht so.
Der zweite Punkt dagegen ist jener, der mich so sicher gemacht hat, dass auch der zweite Versuch scheitern würde. Denn die Adresse ist immer noch die „falsche“ mit gekürztem Straßennamen. Entweder hatte ein Google-Mitarbeiter einen guten Tag, oder ich einfach nur Glück.
Jedenfalls noch mal der deutliche Hinweis: Achtet vor dem Verifikationsprozess darauf, dass bei Google Payments eure Namens- und Adressdaten exakt mit eurem Ausweisdokument überein stimmt, um irgendwelches Hickhack mit Support usw. zu vermeiden. Und wenn ihr den Support kontaktieren müsst, nehmt direkt den englischsprachigen E-Mail-Support. Den deutschen Chat fand ich nicht sehr hilfreich, zudem war der auch nur maschinell übersetzt und entsprechend kam es gerne zu Missverständnissen…
15 „Gefällt mir“
Ich nehme mal an, du hast die Alpha-Version über die Google-Gruppe installiert? Dann passt dieser Thread hier besser.
Zu doof bist du sicher nicht. Eigentlich sollte die App „Out of the Box“ funktionieren. Allerdings klingt das verdächtig nach dem Problem, dass auch Tester auf dem Polestar 3 haben. Dort wird die App auch nicht mit Daten gefüttert.
Leider kann ich dazu bisher keinerlei genauere Angaben machen, da ich mir das ganze noch nicht genauer ansehen konnte und du auch die erste Person bist, die sich mit einem EX30 meldet. Ich werde demnächst noch mal direkt auf dich zu kommen, um da etwas nachzuforschen.
Aber magst du vielleicht zumindest ein paar Bilder von der App auf dem EX30 zeigen? Bisher konnte ich nur spekulieren, wie die App auf anderen Fahrzeugen als Polestar 3 und EX40 aussieht 
Was du aber schon mal machen könntest: In den Systemeinstellungen des Autos sollte eine App-Liste zu finde sein. Schau dort beim Car Stats Viewer mal nach, welche Berechtigungen die App dort erteilt bekommen hat.
Oh, und was auch interessant wäre: Werden in EVMap (Einstellungen → Fahrzeugdaten) Echtzeitdaten angezeigt, und ist ABRP in der Lage, Daten aufzuzeichnen? (Die öffentliche variante kenne ich nicht gut genug, um sagen zu können, ob und wo man das dort sehen könnte, es sollte aber irgendwo einen Referenzverbauch geben).
Oh, und die OTA-Version des Autos wäre interessant zu wissen
Genau, über den Test Track. Berechtigungen für Fahrzeuginformationen und Standort sind erteilt.
Hier ein paar Bilder:
Zu ABRP muss ich mal eine Fahrt lang recherchieren, bin damit noch nicht gefahren. Ohnehin laufen unter der derzeitigen aktuellen OTA v1.4 ABRP, Waze etc nur im Stand (!), den Fehler hat Volvo beim Update von 1.3.1 eingebaut. Über einen Workaround kann man aber das ganze umgehen solange man danach nicht aus der App rausgeht. Dachte erst, das sei vielleicht de r Fehler aber CSV zeichnet auch dann nichts auf.
Sorry, Limit für neue User… Deshalb mehrere Nachrichten.
ABRP zeigt aber den Ladezustand der Batterie auch an, sehe ich gerade… Geht also
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.
14 „Gefällt mir“
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…
6 „Gefällt mir“
Da fehlen mir die Worte…
2 „Gefällt mir“
Ganz spontan, off topic von CSV und rein spekulativ, aber aus echtem Interesse gefragt:
- haben wir eigentlich nicht schon seit den Anfängen einen vergleichbaren Effekt mit allen Eingaben für die ABRP App im Fahrzeug?
- Ich wähle eine Option/drücke auf einen Button und warte und warte (allerdings ohne Datenkringel)…und viele vermute(t)en dahinter einen (zu) langsamen Prozessor im Tablet des Central Displays.
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!“
2 „Gefällt mir“
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.
2 „Gefällt mir“
Mir fehlten die Worte.
Jetzt fällt mir gar nichts mehr dazu ein.
1 „Gefällt mir“
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“
1 „Gefällt mir“
