Ich habe für mich
→ KillApps Killapps - Close Running Apps
entdeckt. Man kann gnadenlos ALLE Programme beenden (lassen) oder aber eine benutzerdefinierte Liste.
In meinem Fall wäre es sinnlos, z. B. die Blutzucker-App zu beenden, also hab ich diejenigen Apps rausgesucht, die nicht unabdingbar notwendig sind.
Vielleicht kann der eine oder andere damit was anfangen, früher nutzte ich Android Assistant, dies funktioniert nicht mehr, KillApps tuts (noch) …
LG
-==[Schubsi]==-
Ich habe mal versucht über Nacht verschiedene Möglichkeite zu testen.
Letzte Nacht war gut!
WLAN ein (=keine Mobile Datenverbindung) UND keine einzige App bei Wecker und Einstellungen
in 7 Stunden nur ca. 6% verloren (Kein Flugmodus, Kein Energiesparmodus)
Mal gucken was die Langzeitbetrachtung bringt
Hallo Olli,
1%/h ist für FP4 seit e/OS 3.0 zu viel im Leerlauf. Bei mir ist es nachts im Idealfall eher 2% in 8 h.
Allerdings habe ich nun bei e/OS 3.2 festgestellt, dass es außerhalb von zu Hause mit mobilen Daten ohne sonstige Aktivität plötzlich fast 3%/h zieht. Für mich sieht es stark nach den mobilen Daten aus. Eine Unsicherheit fällt mir noch ein: KDEconnect läuft im Hintergrund und könnte sich aufhängen, wenn es das heimische WLAN nicht mehr findet. Was dagegen spricht: es taucht nicht bei den Stromfressern auf. Dann wäre ich wieder bei den mobilen Daten und was so dran hängt.
Im Screenshot sieht man den Akkuabbau mit mobilen Daten zwischen 10 und 18 Uhr. Zwischen 18 und 20 Uhr wurde das Phone viel mit Display, aber im WLAN genutzt. Danach kaum Nutzung, aber im WLAN.
Das sag ich ja die ganze Zeit. Und es kann durchaus noch mehr sein, der Energieverbrauch hängt einerseits von den Empfangsbedingungen und vom Typ des Netzes ab, andererseits vom traffic.
Was würde eigentlich passieren, wenn man Bliss-Launcher die Hintergrundberechtigung entzieht? Könnte das System dann einfrieren?
Ich hab jetz experimentell bei einer ganzen Reihe Stock-Apps, darunter auch Bliss, die Akku-Nutzung von “optimiert” auf “eingeschränkt” heruntergeschraubt. Läuft seit zwei Tagen prima. (Ich vermute allerdings, dass sich gar nicht viel geändert hat, jedenfalls wenn “optimiert” richtig funktioniert.)
Update V3.4 bringt bei mir keinerlei Verbesserung (erster Eindruck)
Aber auch keine Verschlechterung.
Bei mir zeigt es sich einmal mehr, dass es mit den mobilen Daten zusammen hängt. Sobald ich mein zu Hause mit WLAN verlasse und die mobilen Daten eingeschaltet werden, saugt microG, Unter den System-Apps steht dann statt Display und CPU auch das Mobilfunknetz klar vorne im Verbrauch.
Zu Hause könnte sich der Verebrauch mit 3.4 sogar etwas verbessert haben.
Ich möcht noch mal auf das GitLab ticket von user msp hinweisen:
Ohne viele Unterstützer wird das Problem wohl wieder untergehen …
Ich hab echt die Faxen dicke. Auch bei IODEOS hat sich beim FP4 der gleiche Fehler eingeschlichen. Da ich selber mit nem FP6 arbeite, bekommen meine Frau und unser Sohn mit, dass ein Smartphone auch bequem zwei Tages kaufen kanny anstatt laufend am Ladekabel hängen zu müssen. Da beide mit der Fotoqualität des FP6 nicht zufrieden sind, wird es bei beiden wohl ein Nicht-FP werden. Echt schade! Beide waren mit ihren Fairphones (bis auf die Kameraqualiät) sonst zufrieden - aber das mit der super kurzen Akku Laufzeit geht gar nicht. Ich verfolge den Thread hier natürlich weiter (hab ja noch mehr Kinder, die irgendwann ein Smartphone brauchen werden. Und wenn dann der Bug behoben sein sollte…). Danke für euren Einsatz!
Das mit dem /e/OS Bashing ist nicht ganz gerechtfertigt, weil viele Bugs von Upstream (LineageOS) kommen. Dafür finden sich im Bugtracker diverse Beispiele.
Nur noch mal zu Info:
Naja, die schlechten Dinge von upstream, die guten von /e/ ?
So ist es ja auch nicht.
Ein missglückter Launcher, ein unnötiger Mail-Fork (der auch schon öfters Probleme gemacht hat) sind schon mal auf der /e/ Minus-Allein-Seite.
Weiss eigentlich jemand wie viel /e/ upstream so beiträgt?
Der Accountmanager ist auch ein weiter unnötiger Fork von Davx5.
Den Bliss-Lauchner kann man ja leicht gegen einen Laucher seiner Wahl ersetzen (bspw. Lawnchair).
Weiss eigentlich jemand wie viel /e/ upstream so beiträgt?
Das kann nur das Developer-Team aufklären. Aber eine ähnliche Diskussion gab es schon bei Debian/Ubuntu, den Kernel-Entwicklern etc. pp.
Sorry, aber das ganze finde ich ein wenig extrem gezeichnet: Mit meinem Pixel (neuerdings ein 4a 5G) komme ich im Idealfall über 4 Tage hin, eben weil ich es ganz gezielt und wenig nutze (hauptsächlich für die Überwachung des Blutzuckers, sehr selten für Telefonie und Internetnutzung fast NULL), wenn ich es aber ständig in der Hand habe und damit “RUM-daddle”, bekomme ich den 3854 mAh (schwachen) Akku auch in wenigen Stunden geplättet.
Ich bin mit /e/OS in die Custom-ROMs eingestiegen (mit dem Gigaset 290) und später dann auf LineageOS abgedriftet (beim Nokia 6.1+), weil die immer nen deutlichen Tick schneller waren.
… und hier kommt jetzt der konstruktive Teil meines Beitrags: Keine Ahnung, wie iodeOS (im Vergleich) so tut, ich hätte empfohlen, es mal mit LineageOS zu versuchen, mindestens ein mal ohne__Datenübernahme, sondern pur und “from scratch” (sagt man so, glaube ich: “from the beginning, without using anything that already exists”)…
Es gibt sicherlich einige Einschränkungen, was LOS nicht ganz so toll macht, aber eine integrierte microG Variante steht zur Verfügung (https://lineage.microg.org/) und andere Probleme bekommt man vielleicht auch umgangen, je nach dem…
Falls Du Dich drauf einlässt: Viel Erfolg! 
(von einem Lichterfelder)
Als Ergänzung: Das normale LineageOS unterstützt mittlerweile auch microG bzw. das nötige Signature Spoofing, doch muss man microG natürlich manuell installieren. Wenn man gleich microG einsetzen will, ist die von @schubsi verlinkte Variante wohl die bessere Wahl.
