Neue Android App "m365 Plus" für alle Xiaomi Roller: LTGM, DPC, KERS uvm.

[Svencore]

Version 2.0.0: Fixes, fixes, fixes!!

Ich hab nicht groß Zeit dazu was zu schreiben, aber die Version ist jetzt oben. Neben einer UNZAHL an Bugfixes gibt es jetzt zwei neue Dialoge:
1. Wenn die BLTID fehlt, wird nun ein Hinweis angezeigt und die App danach beendet
Anhang anzeigen 19978

2. Der Scooter Name kann nun wahlweise in die BLE oder in die APP geschrieben werden ( Svencore):
Anhang anzeigen 19977

Super und ein herzliches Dankeschön!!!Echt klasse wie du dich da reinkniest zum testen komme ich auch gerade noch nicht richtig, leider

 

[nobbes65]

Hatte, nachdem die 1.9.9 auf der Kurzstrecke stabil lief, heute auf Langstrecke mehrere Bluetooth-Abbrüche. Hab dir die Logs als zip per E-Mail zugeschickt. Das Update auf 2.0.0 habe ich gerade erst vorgenommen und werde erst morgen zum testen kommen. Feedback folgt.

Hatte nach dem Update auf 2.0.0 weiterhin gelegentlich Bluetooth-Abstürze. Beim Versuch, Bluetooth neu zu starten, reagierte die App nur mit einem Whitescreen und musste abgeschossen und neu gestartet werden, dabei wurden dann die bisherigen Tripdaten übernommen.

 

[nandtek]

N nobbes65 Vielen Dank für deinen Test und die Email mit den Logs!

Ich bin das Logfile mal durchgegangen und versuche zu rekonstruieren:

Gestern
App gestartet um 21:04
Verbindung beendet um 21:41

Innerhalb dieser ~40min traten keinerlei Fehler auf. Die Verbindung wurde sauber beendet, entweder bewusst oder aufgrund vom Bluetooth Empfang.
So weit korrekt?

Heute
App gestartet um 12:59
App Absturz um 13:06

Zum Absturz: Ich habe den Fehler nachverfolgt und dieser kann nur auftreten, wenn 1. die App in den Hintergrund gebracht wird und 2. Android die App "optimiert", d.h. Speicher freigibt. Wenn du danach wieder in die App zurück wechselst, sind dann alle Objekte die beim Starten der App erstellt werden nicht mehr da und es kommt zu einer NullPointerException bei der Einstiegsfunktion `onCreate()` (siehe Bild im Anhang).

Ein paar Fragen dazu:
1. Kann es sein, dass du die App in den Hintergrund schickst und dann das Handy sperrst?
2. Falls die App nicht dauerhaft im Vordergrund läuft, sind Akkuoptimierung und andere Späße für die App ausgeschaltet? Das von dir genannte Verhalten (Bluetooth Verbindungsabbruch, App Abstürze) ist eigentlich sehr typisch für Android, wenn man diese Optimierungen nicht ausstellt, irgendwann werden die Apps automatisch gekillt. Siehe dazu hier:

Um Links zu sehen, melde dich bitte an

Von meiner Seite werde ich die ein oder andere NullPointer Exception für diesen Fall noch abfangen, mehr kann ich da aber nicht tun.

LG

 

[misternote]

ist die App denn OS in einem Git? Ich bin einer der (vor langer Zeit) Lifecycle-aware/LiveData Mitentwickler und kenne mich noch etwas aus.

Der Anhang sieht mir stark danach aus, als wäre hier die GUI unsauber entwickelt (was nicht heißt, dass die App schlecht sei!).

" Falls die App nicht dauerhaft im Vordergrund läuft, sind Akkuoptimierung und andere Späße für die App ausgeschaltet? Das von dir genannte Verhalten (Bluetooth Verbindungsabbruch, App Abstürze) ist eigentlich sehr typisch für Android, wenn man diese Optimierungen nicht ausstellt, irgendwann werden die Apps automatisch gekillt. Siehe dazu hier:

Um Links zu sehen, melde dich bitte an

" - Genau hierfür gibt es Permissions, um die App nicht von der Akkuoptimierung zu killen - und selbst wenn, dann sollte das noch Abfangbar sein.

Falls du die App irgendwo im Git hast, gucke ich gern mal darüber.

Liebe Grüße

 

[nandtek]

Der Anhang sieht mir stark danach aus, als wäre hier die GUI unsauber entwickelt (was nicht heißt, dass die App schlecht sei!).

Das stimmt vollkommen. Eigentlich müsste man die GUI komplett neu schreiben.

Das Java Backend ist im

Um Links zu sehen, melde dich bitte an

, wenn du willst kannst eine GUI schreiben und contributen, weil mir fehlt dafür Erfahrung mit Android und Frontend generell. Dort habe ich auch eine Lib für Ninebot, die ich in meiner App nie eingebaut habe.

Genau hierfür gibt es Permissions, um die App nicht von der Akkuoptimierung zu killen - und selbst wenn, dann sollte das noch Abfangbar sein.

Danke für den Hinweis, kannte ich nicht. Ist es REQUEST_IGNORE_BATTERY_OPTIMIZATIONS?

LG

 

[misternote]

Um Links zu sehen, melde dich bitte an

Unter anderem, ja. Allerdings ist es die Sache des Herstellers (Samsung, Google (Pixel), HTC, ..) ob sie die Permissions für non-system-apps erlauben. Samsung erlaubt es allerdings definitiv, genauso wie Xiaomi und Lenovo.

Die Frage ist nur, wieso sollte man überhaupt den Batteriesparmodus deaktivieren? Ist die App inaktiv, serialisiert sie halt eben alles. BT sollte ja problemlos reconnecten.

 

[nobbes65]

@nobbes65 Vielen Dank für deinen Test und die Email mit den Logs!

Gestern
App gestartet um 21:04
Verbindung beendet um 21:41

Die Zeiten gestern sind mir nicht ganz schlüssig, war kurz vor 20 Uhr am Ziel (kein Abbruch) und hab den Roller bis ca 23 Uhr ausgehabt. Von der Rückfahrt gab es keine Daten im Log? Bei der Ankunft vor der Haustür hatte ich auch einen Abbruch.
Die Zeiten von heute sind dagegen auf die Minute korrekt inkl. Abbruch der Bluetooth-Verbindung.

Dank deines Tipps habe ich die App-Einstellungen geändert, siehe unten:
- Im App Timer einen höheren Wert eingestellt und die Berechtigung für ungenutzte App entfernt
- Bei "Mobile Daten" Hintergrunddatennutzung und Verwendung bei Datensparen aktiv gestellt
- Akku von "Optimiert" auf "Nicht eingeschränkt".
Wahrscheinlich habe ich die ein oder andere Option jetzt unnötig umgestellt, aber die Sache mit der Akkueinschränkung ist einleuchtend.

 

[nandtek]

Die Frage ist nur, wieso sollte man überhaupt den Batteriesparmodus deaktivieren?

Um eine nahtlose Messdatenaufzeichnung zu haben. Bluetooth soll ja nicht getrennt werden.
Bei meinem Mailprogramm musste ich das auch machen, sonst gibts keine Push Nachrichten.

Ist die App inaktiv, serialisiert sie halt eben alles.

Gute Idee.

 

[misternote]

Wakelock.

Sowas realisiert man am besten mit einem gebundenen Foregorund-Service. Eine andere saubere Lösung gibt es imho nicht mehr.

Wakelocks sind gefährlich, wenn nicht anständig benutzt. Viele Hersteller erlauben nur keepalive mit Foreground-Service und Icon (aus Sicherheitsgründen).

Anders würde ich auch bei so präzisen Daten nicht arbeiten. Portieren in einen FG-Service geht super schnell.

 

[nandtek]

Wakelock.

"Creating and holding wake locks can have a dramatic impact on the host device's battery life. Thus you should use wake locks only when strictly necessary and hold them for as short a time as possible. For example, you should never need to use a wake lock in an activity. As described above, if you want to keep the screen on in your activity, use

Um Links zu sehen, melde dich bitte an

.


One legitimate case for using a wake lock might be a background service that needs to grab a wake lock to keep the CPU running to do work while the screen is off. Again, though, this practice should be minimized because of its impact on battery life."


FLAG_KEEP_SCREEN_ON ist bei mir schon drin. Bei Wakelock bin ich zurückgeschreckt wegen dem Text.