Mein Motorola G4 Play (Harpia) lief seit /e/ OS 0.14 einwandfrei bis einschließlich OTA Upgrade 1.3,
nach dem Upgrade auf 1.5 hängt das System mehrmals täglich.
Eingaben sind dann nicht / nur extrem zeitverzögert möglich, Apps stürzen ab und alsbald bootet das System automatisch mehrmals täglich neu.
Nach dem Reboot läuft es für paar Stunden normal, dann beginnt das Spiel wieder von vorn.
Das Phänomen geschieht auch in Ruhe ohne Benutzung sowie über Nacht im Flug / OfflineModus,
der Akku wird dabei extrem beansprucht und verliert selbst in Ruhe und über Nacht 25-40% Ladung
(bis /e/ 1.3 waren es max. 5% Ladung).
Das Phänomen begann das erste Mal nach dem Upgrade auf 1.5 ,
genervt davon habe ich sehr bald auf 1.6 nach Erscheinen aktualisiert (was ich so schnell sonst bei KEINEM OS mache),
ohne Besserung.
Aktuell prüfe ich noch ob es eine Verbesserung gibt wenn ich den Standard “BlissLauncher”
statt dem von mir seit /e/ 0.14 präferierten “OpenLauncher” verwende.
Für weitere Ratschläge oder Hilfe bin ich aber offen.
Freezes / Instabilität habe ich bei dem eigenen harpia das jeden Tag läuft keine. Auch zu den harpias die ich verteilt habe kommt das nicht als Rückmeldung. Nur AppLounge schließt sich ggf mal selbst wenn es ohne Token ist. Den Grund kannst Du eingrenzen wenn Du nebenher “adb logcat” laufen lässt und nach Exceptions Ausschau hältst.
Akku: seit einer der höheren v0.20ern oder v1.0 zieht das Android mehr als zuvor, aber nicht soviel dass ich dem nochmal auf den Grund bin.
Die Akku-Sinkrate war mal sehr gut in v0.17-q (siehe Screenshot Moto battery drain comparison - #15 by tcecyk) - mit dem dort verlinkten Tool könntest Du die Ursache herausfinden was das auf 3-4% pro Stunde bei dir bringt - user wakelocks waren in meinem Fall bisher verantwortlich (der Wetterwidget) wenn im Leerlauf der Verbrauch >1% war. Irgend ein Prozess lässt die CPU nicht schlafen.
Nach OS-Updates empfiehlt es sich immer, den Cache von apps zu leeren. Es gibt extra tools dafür (F-Droid: Suchwort “Cache”), die das gleich für alle apps machen (wäre aber vorsichtig). Ich würde zunächst mal schauen, das für die diejenigen apps manuell zu machen, bei denen häufig Abstürze erfolgen. In der Regel lösen sich dadurch sehr viele Probleme (inkl. hohem Akku-Verbauch).
Insgesamt muss ich sagen hat sich mein Akku-Verbrauch in den letzten Monaten eher verbessert (!).
Die Batteriesinkrate war auch bei mir wie beschrieben immer gut bis einschließlich /e/ 1.3,
erst nach Upgrade auf 1.5 traten die Probleme auf.
Das ganze System hängt und frißt sich scheinbar im Hintergrund mit RAM voll (lt. Android Assistant),
der dann erst die laufenden Apps abstürzen lässt, dann das ganze Garät.
Das Problem tritt weiterhin auch auf, wenn ich über den “Android Assistant” alle im Hintergrund laufende App-Prozesse beende (“Beenden erzwingen”).
Für mich sieht das nicht so aus, als wenn eine App dafür verantwortlich wäre,
zumal seit /e/ 1.3 keine App dazu kam.
Die im “Adroid Assistant” aufgeführten CPU-Lasten der Apps sehen aktuell in /e/ 1.6 genau so aus wie in /e/ 1.3.
Ich kann trotzdem gern nochmal einen “Cache-Wipe” machen und jeden Cache der Apps einzeln löschen,
ob das aber bei nicht laufenden Apps etwas verbessert erschließt sich mir noch nicht,
aber ein Test schadet natürlich nicht.
Nachtrag:
Der verwendete Launcher (aktuell Bliss statt OpenLauncher seit 0.14) brachte keine Verbesserung.
Nachtrag2:
Das Gerät ist nicht gerootet !
Betterbatterystats wird dann wohl leider nicht funktionieren, wo muß ich “adb logcat” eingeben?
wenn andere Apps wegen Speicherknappheit beendet werden kommt eigentlich nur eine andere App in Frage. Kann auch eine system App sein die nicht klarkommt.
Im Zweifel factory-reset und eine Zeit lang ohne viel Extras verwenden.
haha das war doof ja - Batterie-Entladerate wäre weniger falsch - highly advanced deepl.com schlägt auch Batterieentladungsgeschwindigkeit vor, ein - wenn man es sich in Schulschrift vorstellt - tolles Wort
Ich habe vor 9 Tagen alle Caches geleert und nochmal alle App-Prozesse,
selbst solche systemnahen die noch nicht mal im “Android Assistant” angezeigt werden,
händisch und in Kleinstarbeit über das Systemmenü mit “beenden erzwingen” ausgeschalten.
Dann wieder nach und nach die von mir genutzten Programme/Apps einzeln geladen,
sowie von Bliss wieder auf OpenLauncher zurück gewechselt.
Bis Stand heute läuft das Gerät ohne Probleme, keine Neustarts, keine Apstürze, Akkustand auch über Nacht kaum niedriger (jedoch natürlich ohne einen kompletten Neustart gemacht zu haben).
Das beschriebene Problem wird also allem Anschein nach schonmal nicht von einer von mir genutzten App verursacht.
Ich kann jetzt nach und nach auch die von mir nicht genutzten App-Prozesse wieder starten und dann schaun wir mal.
Mittlerweile habe ich über e/OS 1.7 auf 1.8.1 aktualisiert.
Die Abstürze und Reboots treten zwar nicht mehr auf, trotzdem wird der Akku NUR IM FLUGMODUS über Nacht alternierend um etwa 30% leergesaugt,
(trotz Deaktivierung aller im Hintergrund laufenden Benutzer-Apps über den “Android Assistant”) .
Das Problem tritt ohne aktiviertem Flugmodus explizit nicht auf.
Einzige Ausnahme:
Wenn der “Privacy Browser” im Hintergrund aktiv ist, der dann scheinbar trotzdem ein paar Ressourcen für sich beansprucht.
Ich kann das Problem also weiterhin nur umgehen, indem ich das Moto G4 Play nicht in den Flugmodus schalte.
Ausgeschaltene Mobile Daten oder Wlan haben darauf ebenfalls keinerlei Einfluß.
Es gibt einige Apps, die nachweislich mit dem Flugmodus Probleme haben. Ich hatte vor Jahren mal so ein Exemplar. Das war so eine Netzwerk-Überwachungsapp, die die Bytes zählt, die man versendet und empfangen hat. Da muss man ziemlich aufpassen, was man installiert. Einige funktionieren üblicherweise (also mit Netz) einwandfrei, ohne Netz jedoch versuchen sie offenbar, ihre schiefgegangenen Aktionen nochmal und nochmal und das kostet dann ordentlich Akku.
mein harpia ist jede Nacht im Flugmodus. Die Entladerate über 8 Stunden Premiumschlaf sind <0,5/h, also komme morgens mit 4% weniger Akku aus dem Traumland. Das sind unveränderte Werte zu 2021 bis zur aktuellen /e/-1.11. Siehe dem Link weiter oben mit adb bugreport und battery-historian wie ich draufschaue. Letzteres Tool kann Dir gut anzeigen was gegen den Flugmodus anläuft, weniger Spekulation
Ich mache immer wieder Werbung hier im Forum oder im Bugtracker dafür. Wenn man mit der Zeit wakelocks versteht und mit der Maus über den Gründen fürs Aufwachen der CPU “hovert” kristallisiert sich ein Schuldiger heraus.
Besser als die Apps auf dem Gerät, aber wegen adb + docker nicht für alle zugänglich verständlicherweise.
Danke Dir.
Oja das sieht eingermaßen mächtig aus
Mein Fehler … ich hatte in fdroid und im playstore nach einer app gesucht und dort natürlich nur das übliche Zeugs gefunden …
War auf dem Moto G4 Play seit e/os 0.14 bis einschließlich 1.3 auch so wie von dir beschrieben,
maximal 4-5% Verlust nachts im Flug.
Das OS ist nicht gerootet, also werden viele solcher Äpps gar nicht laufen.
Ich hab ehrlich gesagt auch noch ein paar andere Sorgen als mich (seit e/os 1.x) ständig als “Beta-Tester” mit dem Moto G4 Play beschäftigen zu müssen.
Wenn das weiterhin so grot läuft → anderes Mobiltelefon oder anderes OS.
eine App kann schon den Unterschied machen. Wenn Dir adb zur Verfügung steht (vom flashen?), Du “adb bugreport harpia.zip” ausführst und die Zip Datei in https://bathist.ef.lc/ öffnest findest Du ggf etwas. Root ist dafür nicht notwendig. Die Wakeup Events während dem Flugmodus sollten einen Hinweis geben.
Ja, aber irgend eine Äpp saugt im Flugmodus Deinen Akku leer.
Was sagt denn die Akkunutzung in den Einstellungen? Der Verdächtige müsste dort ja auf der Liste ganz oben stehen (natürlich nachdem Flugmodus mal längere Zeit benutzt wurde).
Negativ, da hatte ich schon öfter mal geschaut,
man sieht nur den “Akkusinkflug” ohne das ein Verdächtiger aufgelistet wird.
(Kein Wunder, ich beende Nachts alle meine offenen Äpps über den "Android Assistenten)
Außer:
(Für das Phänomen habe ich erst gar keinen Beitrag aufgemacht…)
:
Heute, mal wieder in der Gesäßtasche, im Standby versehentlich die Kamera aktiviert.
Im Ergebnis sinkt der Akku in kurzer Zeit von 60% auf 30%, bis ich es bemerkte (siehe Anhang).
Ärgerlich, aber wohl nicht zu ändern.
Ps: Die Schnappschüsse sollen nur zur Veranschaulichung dienen und hoffentlich nicht zu Grundsatzdiskussion zu einzelnen Programmen führen, wie so häufig.
schlägt auch Batterieentladungsgeschwindigkeit vor, ein - wenn man es sich in Schulschrift vorstellt - tolles Wort
