News Schließen von Apps: Smartphone-Hersteller für Batteriesparer in der Kritik

[PcM-Fr34K]

Ich habe das Nokia 8 mit Android P und habe noch nie erlebt, dass ich Pushnachrichten erst mit dem öffnen der jeweiligen App bekomme oder dass mein Wecker nicht läutet. Die Akkulaufzeit ist auch bei dauerhafter Nutzung viel besser als bei dem Xperia, dass ich vorher hatte. Auch wenn ich Apps wie den Runtracker (trackt im Hintergrund meine Bewegung per GPS) benutze funktionieren die über mehrere Stunden einwandfrei, ohne das sie geschlossen werden.

 

[micv]

Kann ich vollkommen zustimmen bei Xiaomi. Ist schon immer bei denen so. Seit ich mit Miui 5 dabei bin. Man muss apps extra sperren wenn man nicht will, dass die gekillt werden irgendwann.

 

[metzgore]

Wenn ich das richtig interpretiere, beduetet das also, dass mein Wecker nicht klingeln würde, wenn ich mein Handy reboote und danach die Wecker-App nicht nocheinmal ausführe - denn dann kann die App die nötigen Alarme ja nicht erneut setzen.
Oder bin ich auf dem Holzweg?
Wenn es wirklich so ist, würde ich mir als Entwickler auch 3mal überlegen, ob ich die Funktion nutze. Der System-Wecker wird bestimmt auch über einen Reboot hinaus gespeichert...

Wenn man es richtig programmiert, geht das relativ easy. Man muss sich praktisch die Alarme wegspeichern (Datenbank oder ähnliches). Dann gibt es eine Berechtigung in Android, damit eine App erfährt, dass das Gerät gerade neugestartet wurde. Es wird dann eine Systemnachricht für dieses Event gesendet, welche eine App-Komponente empfangen kann, damit diese die Alarme wieder im System registriert.

Source: Ich entwickel Android-Apps

 

[Redirion]

Wenn ich das richtig interpretiere, beduetet das also, dass mein Wecker nicht klingeln würde, wenn ich mein Handy reboote und danach die Wecker-App nicht nocheinmal ausführe - denn dann kann die App die nötigen Alarme ja nicht erneut setzen.
Oder bin ich auf dem Holzweg?

Holzweg. Wie würde deine App ohne Alarmmanager dann den Reboot überstehen? Die müsste dann ja auch wieder ihren Hintergrundprozess starten. Die Problematik ist da genau die gleiche.

Es gibt nur einen Showstopper: Wenn man Systemmenü von Android über "Beenden erzwingen" eine App stoppt. Dann kann sie auch keine Systemereignisse (Broadcasts) mehr empfangen, bis sie zunächst einmal wieder manuell vom Benutzer gestartet wurde. Ich nutze das z.B. aktiv für Skype. Das brauche ich am Handy nur, wenn ich nicht gerade im Büro am Rechner mit Skype bin. Würde Skype immer aktiv sein, würde mein Handy immer mit vibrieren, wenn ich am Rechner eine Skype-Nachricht erhalte. Daher erzwinge ich das Beenden und starte es nur die 1-2x alle paar Tage, die ich es tatsächlich am Handy benötige.

Wenn eine vorinstallierte "Batteriespar-App" (muss vorinstalliert sein, wegen Systemrechten/Signatur), beim ActivityManagerNative "forceStopPackage" aufruft (nicht öffentliche API), würde das dem "Beenden erzwingen" gleichkommen. Dann wäre übrigens diese "Batteriespar-App" das große Übel, dass die fünf Kackhaufen bekommen sollte. Wegen so etwas kommen dann eben von diesen Apps auch keine Notifications mehr.

 

[BrOokLyN R!ot ³]

Also für mich ist das totaler Unsinn. Habe das OnePlus 3T und alle Nachfolger (einschließlich dem 6T) gehabt, sprich von Oxygen OS 6.0 - 9.0 und ich muss sagen ich bekomme alle Push notifications genauso wenn nicht schneller als auf meinem Pixel (Arbeitshandy).

Also sorry aus meiner Sicht völliger Dünnschiss. Das Samsung und andere Schrotthersteller gut abschneiden riecht nach bezahlter Studie.

Es sind nämlich nur erfolgreiche "China Böller" auf der Liste..... Schelm wer da Böses denkt....

 

[Harsiesis]

Oneplus 6 auf dem LiquidRemix mit blu_spark Kernel und zusätzlichem Universal GMS Doze läuft .... keine Probleme. Alle Nachrichten kommen rechtzeitig an.

Dafür hält der Akku locker zwei Tage bei ~7-8Std. SOT.

Auch unterstützt das ROM mit der Smartbar "long press back to kill app". Dies hilf auch noch zusätzlich. Benutzte ich eine App, bin fertig damit, dann wird sie gekillt und läuft somit nicht mehr im Hintergrund weiter. Dann dauert halt der nächste Start der App 0.895s länger.

 

[Drosco]

Um bei deinem iOS Beispiel zu bleiben, dort gibt es eine Hintergrundprozess welcher dir genau dies erlaubt. Die App läuft weiter wenn du Updates deiner Position machen willst. Hier hat Google einfach geschlafen solche Dinge rechtzeitig bereit zu stellen und konsequent einzufordern. Es ist einfach nervig, dass nach einigen Stunden Inaktivität keine Nachrichten mehr ankommen. Da überlegt ich es mir wirklich zwei mal ob ich mir noch mal ein Android kaufe.

Ja für diesen Geofence-Spezialfall gibt es das, aber für andere Szenarien nicht. Z.B. ich will eine Notification zeigen sobald der User 10.000 Schritte am Tag gemacht hat.
Manchmal kann es auch vorkommen, dass ein Backgroundprozess permanent laufen soll, um einen Kommunikationskanal (z.B. über MQTT) offen zu halten. Bei Android geht das. Bei iOS geht das nicht. Das erschwert z.B. Umsetzungen von Apps die im abgekapselt vom Internet in Firmen mit hohen Sicherheitsstandard funktionieren sollen. Da geht dann nicht mal mehr der Workaround über Apple Push-Server.

Wenn eine App zu ist dann ist diese zu. Dann ist der Prozess vom System beendet wurden. Was ist daran nicht zu verstehen?

Lol. Es gibt eben Apps die auch funktionieren sollen, wenn sie "geschlossen" sind. Das gibt es auf Windows genauso wie auf Android. Ein altbewährtes Konzept. Der UI-Prozess wird beendet, ok. Und dann soll es eben was geben, das in einem Backgroundprozess mit entsprechenden Limitierungen regelmäßig (oder dauerhaft) läuft. Ich sage nicht jede App sollte so etwas haben, aber manchmal macht es eben Sinn und dann ist es besser wenn man die Möglichkeit hat. Von mir aus auch nur mit vorherigem explizitem Zustimmen des Users.

Ergänzung (15. Januar 2019)

Was ist daran jetzt unverständlich? Der Task-Switcher ist wie ein Task-Manager. Wenn du die App da rauswirfst, wird sie komplett gekillt. Ergo findet der Background-Fetch bei der nächsten Runde keine App zum aufwecken und kann nicht durchgeführt werden. Ein kompletter App-Neustart nach explizitem Close vom Benutzer wird vom Background-Fetch nicht ausgeführt.

Das kommt halt davon, dass sich viele kramfphaft angewöhnt haben, Apps sofort nach der Benutzung zu schließen. Ja, auf meinem Low-End Android for 5 Jahren hat das auch noch merklich was gebracht (und lag da schon an schlechtem Memory Management auf OS Seite). In den letzten 2-3 Jahren hatte ich allerdings kein Gerät mehr, wo das irgendwie von Vorteil gewesen wäre.

Aber ich kenne genug Leute, die da immer fleißig alle Apps schließen (sowohl Apple als auch Android) und sich dann beschweren, dass Benachrichtigungen nicht mehr ankommen oder so. Auf dem PC erwartet aber keine, dass Outlook noch Benachrichtungen zu neuen Mails anzeigt, wenn man das Programm komplett killt, statt nur zu minimieren...

Bei meinem iPhone schmeiße ich nur eine App aus dem Task-Switcher, wenn sie sich aufgehängt hat. Ansonsten faße ich das Teil einfach nicht an, und alles läuft. Wenn Speicher gebraucht wird, wird die App automatisch geschlossen (bleibt aber im Task Switcher und damit auf der "Starten / Aufwecken" Liste für Backgrounf Fetch). Alles tutti.

Stimme dir prinzipiell zu, für mich ist das krampfhafte Schließen von Apps ebenfalls unverständlich (wenngleich is es selbst auch ab und an mache).
Der Task-Switcher ist aber nur begrenzt mit dem Windows Task-Manager zu vergleichen (ich vermute auf den beziehst du dich). Ich behaupte beide verfolgen ein anderes Ziel und ist bei iOS ein zentraleres Bedienelement, der Zweck ist hauptsächlich um von einer App zur anderen zu gelangen. Ein weiterer Unterschied ist, dass nach einem Reboot bei iOS die zuvor offenen Apps nicht mehr laufen, wohingegen es auf Windows den Autostart gibt.
Es soll natürlich kein kompletter App-Start mit UI gemacht werden, sondern eben nur eine kleine Backgroundroutine ausgeführt werden (mit entsprechenden Ressourcen-Limitierungen), wie bei Android oder Windows UWP.

 

[Alphanerd]

Ja das App killen verbraucht auch Strom

Nur wenn das eine App ist, die immer wieder geöffnet (neu geladen) wird. Da ziehen dann CPU und nand Strom.

Muss man halt je nach App und Nutzungshäufigkeit abwägen, was sinnvoller ist.

und genau von diesen Leuten erwartest du, dass sie auch nur einen Schritt in die Einstellungen wagen

Man muss ein Gerät bedienen lernen: Buch aus der Bücherei, Kurs bei der VHS, "Kurs" bei Enkeln/Kinder etc.
Ansonsten nutzt man ein Featurephone.

Gut, dass die Android bald einstampfen. Ich hoffe, dass dieses entfernen der 2 Jahre Updategarantie das Ende von Android andeutet.

Sehr intelligenter Wunsch. Dann darfst du nur 2500€+ für das kleinste/älteste iPhone zahlen.

Mich persönlich nervt eher, daß ich nicht weiß was läuft denn im Hintergrund. Beim PC weiß ich es oder kann nachsehen, außerdem ist ein Programm beendet, wenn ich es schließe.

Klappt bei Android auch. Du kannst nicht erwarten, dass man alles so einfach findet, wie bei einem OS, das man schon Jahrzehnte nutzt. Die Suchfunktion am Handy hilft dir aber dabei.

 

[fuyuhasugu]

Dafür gibt es bei Android den Alarmmanager. Da muss kein Hintergrunddienst für laufen.

„Von hinten durch die Brust ins Auge“ ist wohl die passende Beschreibung für die Funktionsweise und die zu beachtenden Fallstricke dieser „Funktion“.

Bei iOS werden Background Fetches überhaupt nicht mehr ausgeführt, sobald die aus dem Task Switcher geworfen wird - ohne Option für den User, eine App zu whitelisten. Inwiefern soll das besser Verhalten besser sein verglichen mit Android?

Als erstes ist das Quark, denn dan würden die ganzen SNS-und Nachrichten-Apps ja auch nicht mehr funktionieren. Bei anderen Apps hast du den entscheidenden Punkt bereits selbst genannt: der Nutzer beendet die App, nicht jedoch das Betriebssystem um irgendwelche ominösen Energiesparmaßnahmen umzusetzen.

ich will eine Notification zeigen sobald der User 10.000 Schritte am Tag gemacht hat.

Das ist genau das, was auch die ganzen Sport- und Wander-Apps machen. Wenn die das hinbekommen, kannst du das bestimmt auch. Die App muss jedoch die ganze Zeit laufen, das bedingt schon die von dir geforderte Funktion. Du könntest natürlich auch einen Hintergrunddienst bauen, der die App jedesmal startet, wenn ein Schritt getan wird. Aber das entspräche eher der oben bereits genannten Herangehensweise.

Manchmal kann es auch vorkommen, dass ein Backgroundprozess permanent laufen soll, um einen Kommunikationskanal (z.B. über MQTT) offen zu halten. Bei Android geht das. Bei iOS geht das nicht. Das erschwert z.B. Umsetzungen von Apps die im abgekapselt vom Internet in Firmen mit hohen Sicherheitsstandard funktionieren sollen. Da geht dann nicht mal mehr der Workaround über Apple Push-Server.

Als Pull auch als Dienst eigentlich kein Problem. Mit Push muss die Anwendung natürlich geöffnet sein. Aber so ganz reicht die Erklärung nicht, um hier eine qualifizierte Aussage zu treffen.

 

[Supergurki]

Hab ich auch schon gemerkt. Kriege häufig erst Push-Benachrichtigungen wenn ich Apps wieder öffne oder der Google Play Store die App aktualisiert. Gerade bei Messengern ist das dezent nervig.

Ist ja gut, dass es nur dezent nervig ist. Man stelle sich vor es wäre sehr nervig. Oder extrem nervig.

Ergänzung (15. Januar 2019)

Komisch, ich habe mit meinem Huawei P20 pro überhaupt keine Probleme. Von Anfang an lief da so ziemlich alles glatt. Mein GPS Tracker funktionierte zwar erst nicht im Hintergrund, was im ersten Moment ziemlich blöd war, weil ich eine gute Strecke gelaufen bin. Aber dann habe ich einfach in den Optionen das Akku nachgeschaut und dem Tracker auch das laufen im Hintergrund erlaubt. Funktioniert alles absolut einwandfrei.
Wer sich da beschwert sollte sich einmal mit seinem Gerät auseinandersetzen.

 

[AntiUser]

Manchmal kann es auch vorkommen, dass ein Backgroundprozess permanent laufen soll, um einen Kommunikationskanal (z.B. über MQTT) offen zu halten. Bei Android geht das. Bei iOS geht das nicht.

Du hast es erfasst, es geht nicht und es wird hoffentlich auch niemals funktionieren. Wenn man so etwas implementiert sieht man die Folge ja hier in dieser Diskussion. Die Hersteller fangen an knallhart Hintergrundprozesse zu schließen, da diese zu viel Energie umwandeln.

Es gibt eben Apps die auch funktionieren sollen, wenn sie "geschlossen" sind.

Nicht bei iOS. Wenn du eine solche App entwickeln willst, dann bist du mit deinem App basierten Ansatz unter iOS einfach falsch. Hier würde ich ein Ansatz mittels Server empfehlen, welcher die Verbindung offen hält und dir auf dein App einfach mittels Push eine Nachricht schickt. Wenn du die App öffnest kannst du die Daten laden und direkt anzeigen. Wenn der Weg nichts für dich ist, dann musst du unter Android entwickeln. Aber auch hier Obacht welches System du verwendest, viele werden dir den Prozess beenden (genau darum geht es hier ja).

 

[psYcho-edgE]

was im ersten Moment ziemlich blöd war

Nur gut dass es nur ziemlich blöd war. Und nicht heftig blöd. Oder maximal blöd.

 

[Drosco]

Du hast es erfasst, es geht nicht und es wird hoffentlich auch niemals funktionieren. Wenn man so etwas implementiert sieht man die Folge ja hier in dieser Diskussion. Die Hersteller fangen an knallhart Hintergrundprozesse zu schließen, da diese zu viel Energie umwandeln.

Ich wiederhole mich, aber warum sollte das nicht gehen, wenn zuvor explizit die Zustimmung des Users eingeholt wird? Und von mir aus zusätzlich noch eine sticky Notification, die darauf hinweist, dass im Hintergrund etwas läuft? Dann kann sich keiner beschweren.

Nicht bei iOS. Wenn du eine solche App entwickeln willst, dann bist du mit deinem App basierten Ansatz unter iOS einfach falsch. Hier würde ich ein Ansatz mittels Server empfehlen, welcher die Verbindung offen hält und dir auf dein App einfach mittels Push eine Nachricht schickt. Wenn du die App öffnest kannst du die Daten laden und direkt anzeigen. Wenn der Weg nichts für dich ist, dann musst du unter Android entwickeln. Aber auch hier Obacht welches System du verwendest, viele werden dir den Prozess beenden (genau darum geht es hier ja).

Erklär das mal dem Kunden, der so eine Anforderung stellt. Mir ist unter iOS keine Möglichkeit bekannt, mittels Server eine Verbindung offen zu halten, die auch nachdem die App minimiert oder geschlossen wird bestehen bleibt. Apple Push Notification fällt jedenfalls raus, denn wir verfolgen eine On-Premise-Lösung ohne Anschluss zum Internet. Lasse mich da gerne eines besseren belehren.

 

[Hylou]

Man muss ein Gerät bedienen lernen: Buch aus der Bücherei, Kurs bei der VHS, "Kurs" bei Enkeln/Kinder etc.
Ansonsten nutzt man ein Featurephone.

Dein Post ist das perfekte Beispiel für den Technik afinen Menschrn der so absolut 0 Verständnis dafür hat, dass andere Menschen diesen Enthusiasmus nicht teilen.

Deinem Posting zufolge dürften nur ca 10% der Leute überhaupt ein Smartphone besitzen.

 

[crustenscharbap]

Sehr intelligenter Wunsch. Dann darfst du nur 2500€+ für das kleinste/älteste iPhone zahlen.
.

So doof ist Google natürlich nicht. Sie haben Fuchsia am Start, was so wie Windows oder iOS laufen soll. Ich denke mittelfristig wird dies Android ersetzten. Meine Vermutung ist, dass in ca 2 Jahren die ersten Fuchsia Geräte kommen. Die gibt es parallel zu Android und iOS. Die werden sich immer mehr verbreiten und irgendwann Android überschatten. Seit neuem kann Fuchsia sogar Android-Apps öffnen.
Meine Vermutung ist folgende: Android Q wird das letzte Android. 1. Google Apps laufen auf ein iOS Gerät besser. 2. Google hat dieses 2-Jährige Updateversprechen von Android One und Pixel entfernt. 3. Google weiß selbst von den Problemen und hat mehrere Ansätze dies zu lösen aber Android bzw. Linux war nie vorgesehen auf Smartphones zu laufen. Auslagerung der Bibliotheken in Apps, (Google Play Dienste, Carrier Services, AR-Core uvm). Dann kam Android One, jene Geräte eher einer Beta gleichen. Jedes für Smartphones optimierte System hat folgende Probleme nicht: Input lagg, Speicherverwaltung (Thema Apps schließen), Mirkroruckler, Akkuverbrauch, Updates. Ein Lumnia 8 oder iPhone 5 läuft flüssiger als ein Pixel 3. Egal ob Windows Phone, iOS Tablet oder iPhones. Der Standby Drain ist weit unter jedem Android Phone. Mein iPhone 8+ hält wesentlich länger, als mein Nokia 7%, trotz 30% kleinerem Akku und schnellerem Prozessor.

Zurzeit ist mMn iOS Android haushoch überlegen. Wäre nicht die iTunes Bindung und es nicht so verschlossen (NFC, Bilder raufkopieren, Musik übertragen, Klingeltöne usw.) Ohne diese Beschränkungen würde ich sofort zum iPhone greifen. Diese stören aber vielen nicht. Daher hat Apple bei 80% der Kunden freien zulauf und könnte die Preise drastisch anziehen. Wäre von Apple äußerst schlau und absolut nachvollziehbar.

 

[Alphanerd]

Dein Post ist das perfekte Beispiel für den Technik afinen Menschrn der so absolut 0 Verständnis dafür hat, dass andere Menschen diesen Enthusiasmus nicht teilen.

Ich kann mein Kfz nur rudimentär warten, ich bezahle da ein Profi für. Ich bin Handwerklich unbegabt, ich rufe Freunde/Profis dafür. Bei Familienfeiern mache nicht ich die Fotos, zu doof dafür. Wenn ich ein neues Gerät bekomme, das mir Fragen aufwirft greife ich zum äußersten: ich lese die Anleitung.

Warum verhält man sich bei einem Taschencomputer/Smartphone anders?

Es sind die selben Leute die Probleme haben, die schon in den 80ern/90ern ihren VHS Recorder nicht programmieren konnten/wollten.

 

[m4c1990]

Also deswegen kommt mein Redmi Note 5 manchmal 3 Tage, bei normaler Nutzung, ohne Laden aus? Interessant.

 

[Austrokraftwerk]

Stimmt es, dass man bei iOS keine Apps schließen soll weil das dem Gerät nicht gut tut und man damit ohnehin keinen Strom spart?

Dem Gerät tut es nicht weh
Allerdings brauchst dich nicht wundern, warum Apps immer so lange zum starten brauchen wenn du permanent alles schließt.
Einfach offen lassen und nicht darüber nachdenken....iOS regelt das schon von alleine. Du bekommst dadurch keine "Ruckler" weil der Speicher knapp wird bei bei manchen Android Geräten.

Ich hab fast alle Apps offen und dutzende Tabs im Browser....alles läuft flüssig und ohne Probleme und häufig benutzte Apps sind immer gleich da.

 

[Supergurki]

Nur gut dass es nur ziemlich blöd war. Und nicht heftig blöd. Oder maximal blöd.

Ja, es war nur ziemlich blöd. Hier wäre sogar dezent richtig gewesen.

Ergänzung (15. Januar 2019)

Nur gut dass es nur ziemlich blöd war. Und nicht heftig blöd. Oder maximal blöd.

Aber wir verstehen uns

 

[AntiUser]

Ich wiederhole mich, aber warum sollte das nicht gehen, wenn zuvor explizit die Zustimmung des Users eingeholt wird?

Aber genau das ist ja hier das Thema, viele Hersteller entscheiden sich dagegen. Die meisten User können solche Entscheidungen nicht treffen, weil diese die Auswirkungen nicht verstehen. Darum entscheiden sich viele Hersteller einfach die Prozesse zu beenden. Grade bei Android finde ich das fragwürdig. Ich wünsche mir hier eine Einstellung um das zu umgehen.

Erklär das mal dem Kunden, der so eine Anforderung stellt.

Als Entwickler liegt es dann an dir eine Lösung zu präsentieren oder dem Kunden etwas anderes zu verkaufen. Die einfachste Lösung währe, ein kleiner Server der dauerhaft die Verbindung aufrecht erhält. Trotzdem bekommst du keine Push Nachrichten hin ohne Internetzugriff, zumindest ist mir keine Lösung ohne die Apple Server bekannt. Leider funktionieren nicht einmal WebPush Nachrichten unter iOS. iOS scheint hier einfach die falsche Platform zu sein.