Ich habe jetzt noch mal eine andere Möglichkeit ausprobiert: Es gibt sogenannte Wake Locks. Diese sorgen normalerweise dafür, dass das Android-Gerät wach bleibt. Leider habe ich das nicht zum laufen gebracht, bzw. hat irgendwas nicht funktioniert. Auch mit Wake Lock ist nach 20 Sekunden Schluss gewesen. Oder ich habe irgendwas falsch gemacht, das will ich nicht ausschließen
Mit 0.19.1 vor zwei Stunden habe ich die Ungenauigkeit auch bereits behoben
Die periodisch ablaufende Funktion, die ich dafür missbraucht habe, wurde nicht alle 1000ms ausgeführt, sondern ein paar ms mehr. Nach einiger Zeit werden dann so Sekunden verschluckt.
es gibt in der Auto-API für Android einen CarPowerManager. Allerdings dient der vor allem dazu, dass Apps den Power-Status erfassen können und mitgeteilt bekommen, wenn das Auto vor hat, das Android-System schlafen zu legen.
Damit einher kommt auch der „Garage Mode“. Wenn ich das richtig verstehe, dann wird dieser bei jedem Ausschalten des Fahrzeugs aufgerufen, schaut, ob etwas im JobScheduler steht, und danach geht das Auto in den Schlafmodus.
wenn man sich den „JobScheduler“ ansieht, dann findet man heraus, dass Jobs unter Android 11 maximal 10 Minuten dauern dürfen und 100 Jobs in der Warteschlange stehen dürfen. Ab Android 12 wird die Laufzeit nur noch bei übermäßiger Ressourcennutzung begrenzt.
Ich habe keine Ahnung, ob man diesen JobScheduler für die Zwecke des Wachhaltens missbrauchen kann. Ich werde da mal ein wenig nachforschen und experimentieren. Mein Ziel ist es nicht, dass das Auto unendlich im Garagenmodus bleibt, sondern dass während eine Ladevorgangs die App laufen bleibt, um Ladekurven aufzuzeichnen.
Falls sich da wer auskennt oder Ideen hat, immer her damit. Ich bin auf dem Gebiet absoluter Neuling
Das kann ich nicht beurteilen. Ich würde mal vermuten, dass das getrennt von der Klimaanlage funktioniert. Der JobScheduler ist dafür vorgesehen, bei Nichtnutzung Dinge wie Updates durchzuführen. Das Androidsystem ist also nur im Hintergrund aktiv, ohne aktives Display etc.
Vielleicht kann man den Job Scheduler eher direkt dazu verwenden, im Minutenrhythmus im Hintergrund in einer eigenen Task weiter Ladedaten zu sammeln, anstatt die Haupt-App wachzuhalten. Wenn das Auto/CD wieder aufwacht, kann die App die Daten dann verwursten.
Vielleicht kann ein Job sich auch anschließend wieder selbst neu einplanen? Dann gäbe es faktisch kein „100 Jobs“ Limit.
Wenn ich die Doku richtig verstehe, dann hat die App selber keinen Einfluss darauf, wann die Jobs ausgeführt werden, sondern kann sie nur auf die Liste stellen. Diese Jobs sind explizit für Aufgaben gedacht, deren Ausführung nicht Zeitkritisch ist und außerhalb der Nutzungszeiten durchgeführt werden sollen.
Die Datensammlung liegt ja schon in einem eigenen Service, der die Vordergrundaktivitäten nicht voraussetzt. Jobs sind da noch mal was anderes.
Und ich bin jetzt mal so frei und spiele als vollkommener Laie den Advocatus Diaboli: stell dir vor, da läuft dann etwas schief und er bleibt schön wach und leert langsam, aber stetig die kleine Batterie, oder er verschluckt sich ganz arg beim Abarbeiten der aufgelaufenen Aufgaben, und schon haben wir den Salat…gute Nacht
Schließe mich Walter an, ich wäre auch vorsichtig mit sowas, wenn man sich nicht zu 100% mit dem kompletten System auskennt. Ihr werdet das sicherlich ausführlich testen, aber für mich wäre ein zu tiefer Eingriff in das System, der das Auto zeitweise in einem Halbschlaf hält, auch wenn es nur beim Laden sein soll, ein Grund gegen die App. Ich persönlich brauche eben auch keine Aufzeichnung einer Ladekurve. Und ich kenne es aus meinem Job, wenn einzelne Bereiche einen Teil der Prozesse systemseitig ändern lassen, wird oft genug ungewollt etwas in einem anderen Bereich zerschossen, weil man doch nicht jeden einzelnen Prozess versteht. Nicht mal die IT. Das bisher erreichte ist doch schon klasse. Aber nur meine Meinung, ich werde nur etwas aufmerksamer mitlesen, was genau eingebaut wird. Die App ist nice-to-have aber am Ende doch kein Muss.
Heute früh ist mir folgendes aufgefallen: Nachdem das Auto über Nacht in der Garage stand, startete der Viewer mit dem letzten Trip und führte ihn bei der kurzen Fahrt eben fort. Als der Wagen kurz stand, ohne ihn ihn verriegelt zu haben (2-3 Minuten) und ich wieder losfuhr war der alte Trip gelöscht und er begann von vorn. Ich weiß nicht genau, ob ich den Viewer auf dem CD hatte, als ich das Auto gestern in der Garage abgestellt und verriegelt hatte, aber heute früh, als das Auto kurz unverschlossen stand, war er auf dem CD geöffnet.
Ich denke, in diesem Punkt sind wir uns alle einig. Allerdings kann ich mir eh nicht vorstellen, dass eine App, die nicht systemrelevant und noch dazu Third Party ist, selbst überhaupt so tiefgreifend in die Steuerung eingreifen kann. Die einzige Variante die ich mir vorstellen könnte wäre, dass es extra dafür einen Service unter AAOS gibt, der es zeitlich begrenzt und kontrolliert erlaubt, dass einzelne Anwendungen zweckgebunden und bei ausreichend Ressourcen als Backgroundprozess laufen dürfen.
Ich kann deine Skepsis diesem Punkt gegenüber verstehen. Ich werde auch sicher nichts einbauen, wovon ich nicht überzeugt bin, dass es keine negativen Auswirkungen auf andere Systeme hat.
Der JobScheduler ist ein normales Android-Werkzeug, um außerhalb der Nutzungszeit Aufgaben auszuführen, also quasi genau das, was ich vor habe. Ich würde diese auch nie versuchen undefiniert lange laufen zu lassen, sondern immer zeitlich begrenzen. Am Ende hat immer das Auto das letzte Wort. Es obliegt nicht meiner App, ob der Job ausgeführt wird, sondern die Jobs werden Abgearbeitet, wenn das Betriebssystem der Meinung ist, dass es passt.
Irgendwer hier hatte ein sehr ähnliches Erlebnis letztens. Wo wir schon beim Thema JobScheduler sind: ich würde Mal vermuten, dass der Play Store einen Job auf die Liste gestellt hat, in dem die App aktualisiert wurde, als das Auto kurz abgestellt war. Um die wake locks zu testen gab’s ja gestern noch 0.19.2
Ich werde mich bald darum kümmern, dass Aktuelle Trip-Daten nicht-flüchtig sind, sollte die App beendet werden.
@Kolbenfresser Chris, den Kommentar hättest du dir jetzt wirklich sparen können.
Der „Einwand“ von @WFS Walter ist doch vollkommen berechtigt und auch in Ordnung.
Und es ist -so finde ich zumindest- immer gut, wenn man die Dinge aus unterschiedlichen Perspektiven betrachtet.
@Ixam97:
Ich habe heute früh die 0.19.2 installiert.
„Wake locks“ waren deaktiviert.
Ich beende die App und lösche den Cache immer vor dem Installieren einer neuen Version.
Hat sich bei mir so von der Polestar App „eingebürgert“.
Hat das irgendeinen Nachteil für bspw. irgendwelche Protokolldateien oder so?
Was mir bei der Version aufgefallen ist ist folgendes:
Punkt 1:
Bei der ersten Fahrt hat der Counter (inkl. Sekunden) korrekt hochgezählt.
Rund eine Stunde später (Auto verriegelt), waren die Daten wieder auf null gesetzt.
Zudem wurde die Fahrtzeit dann nur noch alle 5 Sekunden (5 Sekunden-Schritte) aktualisiert.
Ich bin abgesehen davon ohnehin eigentlich eher dafür, dass man die Sekunden komplett verschwinden lässt (analog Fahrerdisplay), da die irrelevant sind.
Punkt 2:
Als ich nach der erste Fahrt, eben rund eine Stunde später wieder ins Auto eingestiegen bin, war das Centerdisplay schwarz (zuvor, sprich vor dem Zusperren, war noch der CSV aktiv).
Beide Punkte sind mir in früheren Versionen nicht aufgefallen bzw. waren nicht vorhanden.
Dies wieder mal nur als ein kurzer, knackiger Bugreport.
Wenn die App mal nen stable release hat, dann wär ich natürlich auch dafür. Aber im Moment macht es schon Sinn zu Testzwecken die Sekunden im Verlauf zu sehen.
