Das Schließen von Apps im Hintergrund verhindern...möglich?

[ebayviper]

cm sollte deodexed sein.

(Deodexed ist leichter zu themen, das weiss ich. Und CM ist leicht zu themen^^
Odexed ist näher am Stock, angeblich dafür etwas schneller......)

 

[satand]

hat sich schon jemand daran versucht? mir ist das ganze etwas zu schwer

 

[DMX]

Ich sehe den Topic erst jetzt, es gibt auch eine andere Methode, mit einem ziemlich netten Tool das von dem User rovo89 entwickelt worden ist. Nennt sich Xposed. Installation ist einfach, man installiert das Core Framework von hier (Xposed Installer runterladen, installieren und in der App auf Install gehen, danach Reboot).

Dann hier noch das passende Modul herunterladen und installieren. Das Modul aktivieren und die App suchen die man immer im Speicher haben will, "Resistant" anklicken und Speichern.

Gibt auch viele andere nette Module hier, ziemlich genial das ganze muss ich sagen.

 

[satand]

Ich sehe den Topic erst jetzt, es gibt auch eine andere Methode, mit einem ziemlich netten Tool das von dem User rovo89 entwickelt worden ist. Nennt sich Xposed. Installation ist einfach, man installiert das Core Framework von hier (Xposed Installer runterladen, installieren und in der App auf Install gehen, danach Reboot).

Dann hier noch das passende Modul herunterladen und installieren. Das Modul aktivieren und die App suchen die man immer im Speicher haben will, "Resistant" anklicken und Speichern.

Gibt auch viele andere nette Module hier, ziemlich genial das ganze muss ich sagen.

danke, das ganze hört sich sehr interessant an. welches modul brauche ich nun genau um gewisse apps im speicher zu halten?

hast du es getestet und funktioniert es wirklich?

 

[DMX]

Das Modul das ich als zweites verlinkt habe, Xposed Settings. Im Speicher halten habe ich nicht probiert, aber die Locale geändert das finktioniert super, wüsste also nicht warum das nicht funktionieren sollte.

Gesendet von meinem Nexus 4 mit Tapatalk 2

 

[satand]

dieses framework ist ja mal DER wahnsinn!!!

man kann damit DPI und font scale per app einstellen, für jede app fullscreen und dauerhaft screen on einstellen, apps im speicher halten (habe noch nicht geprüft ob das wirklich funktioniert) und sogar permissions entziehen (hat openpdroid dann überhaupt noch einen vorteil?).

 

[rambus]

Wie kann man denn das Modul runterladen fand auf der Page keinen entsprechenden Button.

Gesendet von meinem Nexus 4 mit Tapatalk 2

 

[DMX]

Unter der Überschrift auf Description.

Gesendet von meinem Nexus 7 mit Tapatalk 2

 

[rambus]

Ok Modul geladen und installiert, aber eine Option um eine app im Speicher zu belassen kann ich nicht entdecken.

Gesendet von meinem Nexus 4 mit Tapatalk 2

 

[T-119a]

Ich habe mal den Maximum Overdrive Mod getestet und muss sagen ich habe das Gefühl es bleiben mehr Apps offen. Kann dies jemand bestätigen? (Ich kann es leider nicht mehr mit vor dem Mod vergleichen.)

[RC9] ULTIMATIC RC6! [EXE]-=Ultimate Jar Power Tools=-With Maximum MultiTasking Mods! - xda-developers

 

[DMX]

Ok Modul geladen und installiert, aber eine Option um eine app im Speicher zu belassen kann ich nicht entdecken.

Gesendet von meinem Nexus 4 mit Tapatalk 2

Das Modul aktivieren und in die jeweilige App gehen und Resistant anwählen. Hab ich aber alles schon geschrieben, testen müsst ihr halt selber.

 

[FieserKiller]

immer wieder lustig zu lesen wie manch einer glaubt mal eben das speichermanagement neu erfinden bzw besser machen zu können.
Um eine einführung in die thematik zu bekommen empfehle ich das standard einstiegswer modern operating systems von andrew tanenbaum. nach der lektüre des kapitesl zum speichermanagement, die die oberfläche grad mal anreisst, sollte jedem klar werden was das für eine komplexe wissenschaft ist und dass man keine chance hat da was zu verbessern ohne sich ein paar jährchen damit auseinandergesetzt zu haben.
natürlich kann man nach lust und laune herumbasteln, aber die defaults sind nciht ohne grund so wie sie sind. da haben sich nicht umsonst etliche menschen jahrelang mit auseinandergesetzt, alles gebencht und nachgerechnet und sind zu den ergebnissen gekommen dass das ganze so wie es ist, die optimale einstellung ist.

Deswegen gilt die einfache regel: wer da rumfummelt, wird zwar vielleicht irgendwo eine verbesserung für einen bestimmten use-case erreichen, diese fällt einem an anderer stelle dann aber auf die füße. denn wär das setup wirklich besser, wär es längst die defaulteinstellung.

um auf die anfangsfragestellung zurückzukommen, wieso das system den browser unnachvollziehbar abschiesst, einfach mal einen bugreport ausfüllen, die erforderlichen logs beipacken und darauf warten, das sich jemand damit auseinandersetzt und prüft ob es vielleicht ein bug (unwahrscheinlich, kommt aber vor) ist oder alles genau so funktioniert wie es soll und es sehr gute gründe dafür gibt, dass das system sich so verhält, wie es sich verhält.

merke: sich selbst für schlauer zu halten als die experten auf dem gebiet ist eben selten von erfolg gekrönt.

 

[satand]

du hast scheinbar etwas nicht ganz verstanden. es geht eben darum android selbst das speichermanagement zu lassen. welche prioritäten man letztlich selbst bei den apps hat, kann wohl auch google nicht wissen. mit dem ändern des oom-wertes auf "0" sagt man dem speichermanagement quasi nur, dass einem beispielsweise der browser wichtiger ist als youtube, wodurch android youtube zuerst schließt. zumal android für die meisten apps einfach einen standard-wert vergibt.

von speicherverwaltungs-apps, welche android die speicherverwaltung abnehmen, halte ich auch nichts.

 

[FieserKiller]

Der user hat aber eben in den OOM werten nichts herumzupfuschen, das System vergibt schon die richtigen, und zwar nicht einen defaultwert und meist auch nicht nur einen einen per app, sondern abhängig davon, worum es sich handelt, für jeden Prozess der anwendung einen eigenen. Was mit welcher priorität an wen vergeben wird, steht zb hier:
Processes and Threads | Android Developers

Es bleibt dabei, entweder der Browser fliegt zu Recht raus, oder es gibt einen bug im System.

EDIT: noch ein hinweis. wer sich wundert und meint, speicher wär noch über und die anwendungen werden trotzdem abgeschossen, kann sich mal /proc/meminfo auf seinem handy angucken. da ist bei mir zumindest immer nur irgendwas mit 100mb frei, der rest wird von allerlei sachen belegt und das hat auch seinen sinn. pinnt man sich jetzt den browser in den speicher, leiden vielleicht der cache oder irgendwelche buffer darunter und das system muss ständig sachen aus dem flash nachladen, oberflächlich merkt der user davon nichts, und dennoch wird mehr strom verbraucht, die heuristiken kommen auf fehlerhafte ergebnisse weil das system nicht damit rechnet dass da einer rumfummelt, cache misses häufen sich, und alles in allem läuft das system eben nicht so gut wie es könnte, hätte man seine finger davon gelassen.

 

[satand]

mit einem oom-wert von 0 spielt man auf einer ganz normalen ebene für user-anwendungen herum. so sagt man dem speichermanagement nur, dass einem app A wichtiger ist als app B. anders würde es aussehen, wenn man werte von -10 oder noch geringer vergeben würde.

aber bleib bei deiner meinung, du musst es nicht nutzen.

 

[FieserKiller]

nö, mit dem Wert 0 sagst du dem system, dass der prozess grad sichtbar im vordergrund läuft. tut er aber nicht.

jetzt ist der lowmemory driver offensichtlich der hauptkonsument des oom wertes, und er scheint damit offensichtlich zurecht zu kommen, dass du plötzlich mehrere Prozesse mit prio 0 hast, obwohl es auf einem smartphone mit fullscreen-apps eigentlich nur einer sein sollte, eben der, der grad angezeigt wird. wenn er damit nicht zurechtkäme, würd das system da schon die grätsche machen. das passiert aber nur zufällig nicht, trotzdem ist es offensichtlich ein zustand entgegen der spezifikation.
Wenn jetzt noch andere ecken von android zb anhand des oom entscheiden wer grad im vordergrund ist und etwas tut und wer nicht, treffen sie auch auf diese null, die sagt dass der browser grad zu sehen ist. die folgen sind schlicht unabsehbar, undabhängig davon, dass sinnvolles memory managment damit sowieso schon auf der strecke bleibt. Hinzu kommt, dass der kernel den oom ständig anpasst, die app die das festnagelt muss also den wert immer wieder auf 0 setzen, rödelt damit ständig im hintergrund rum und verbraucht strom und speicher.
Und der browser selbst: hey, er sieht dass er grad angezeigt wird, seine View komponente sieht aber dass sie es nicht ist, bzw sieht sie nichts, sie ist ja destroyed. was macht er dann? wahrscheinlich laufen die services und activities irgendwie weiter, also führen munter javascriptschleifen aus, warten auf events, laden was xmlhttprequest ausm netz, was so ein browser abseits der oberfläche halt so tut.

das soll jetzt aber auch von meiner seite aus reichen, jeder darf sich sein system so verbasteln wie er möchte. ich habe hier hoffentlich schlüssig dargelegt wieso es blödsinn ist an sachen rumzufummeln, von denen man keine ahnung hat. wer es trotzdem macht, wird seine gründe schon haben.
Bei windows hat es auch 15 jahre oder so gedauert, bis sich allgemein die meinung durchgesetzt hat, irgendwelche tune-up und one-klick-wir-machen-alles-super, cachelöscher usw. anwendungen mehr kaputt machen als sie nützen, hier ist es genau das gleiche.

 

[satand]

es glaubt jedoch nur das speichermanagement die app wäre im vordergrund. das system selbst checkt sehr wohl, dass die app im hintergrund ist. auch mit einem oom-wert von 0. bei meinem zeitungsapp merkt man dies deutlich, da es aktualisiert sobald ich es öffne, auch wenn es im speicher abgelegt war. weiters kann ich keinerlei akku-drain dadurch feststellen. ich habe keine dadurch verursachte kernel wakelocks, die cpu geht ganz normal in den deep sleep. das ist aber wohl auch verständlich, denn man lässt auch oftmals eine app im vordergrund offen und dreht das display ab. in dem moment ist die app dann auch nicht mehr aktiv.

zumal die für das system selbst wichtigen prozesse ohnehin einen negativen oom-wert haben und schon dadurch als wichtiger eingestuft sind. sollte der speicher wirklich knapp werden, werden auch die apps mit 0 geschlossen.
das framework selbst verbraucht bei mir gar keinen strom oder speicher. ich kann weder über betterbatterystats noch über andere tools irgendwas davon finden. das ist wohl dadurch, dass es das originale android-framework umschreibt und nicht als prozess läuft.

 

[fipsy]

Grins. Den oom-Wert zu ändern bringt - wenn überhaupt - eh nur vorübergehend was. Ich wollte z.B. verhindern, dass der MobileVoIP-Client während eines Callthrough-Telefonats aus dem Speicher geworfen wird und es dadurch zu einer Endlosschleife zwischen dem MobileVoIP-Client und der Telefonanwendung kommt.

Ich habe dazu den oom-Wert mal testhalber auf -17 gesetzt. Da bleibt er auch für ein paar Sekunden stehen, aber nach kurzer Zeit steht er dann wieder auf 8 oder 9 wie zuvor. Wie FieserKiller schon angedeutet hat, überschreibt das System offenbar in schöner Regelmäßigkeit selbst gesetzte oom-Werte mit den seiner Meinung nach "richtigen" Werten. Das Selbstsetzen der Werte bringt also vermutlich gar nix.

So ganz optimal ist die ganze Geschichte wahrlich nicht, wenn man nicht sagen kann, welche Apps - zumindest vorübergehend - den Arbeitsspeicher nicht verlassen dürfen.

 

[blue8]

Grins. Den oom-Wert zu ändern bringt - wenn überhaupt - eh nur vorübergehend was. Ich wollte z.B. verhindern, dass der MobileVoIP-Client während eines Callthrough-Telefonats aus dem Speicher geworfen wird und es dadurch zu einer Endlosschleife zwischen dem MobileVoIP-Client und der Telefonanwendung kommt.

Ich habe dazu den oom-Wert mal testhalber auf -17 gesetzt. Da bleibt er auch für ein paar Sekunden stehen, aber nach kurzer Zeit steht er dann wieder auf 8 oder 9 wie zuvor. Wie FieserKiller schon angedeutet hat, überschreibt das System offenbar in schöner Regelmäßigkeit selbst gesetzte oom-Werte mit den seiner Meinung nach "richtigen" Werten. Das Selbstsetzen der Werte bringt also vermutlich gar nix.

So ganz optimal ist die ganze Geschichte wahrlich nicht, wenn man nicht sagen kann, welche Apps - zumindest vorübergehend - den Arbeitsspeicher nicht verlassen dürfen.

Habt ihr mal den Timer Killer Killer von zeppelinrox ausprobiert? Der Typ hat auch den Supercharger geschrieben, von dem ich aber nicht SO viel halte. Der Timer Killer Killer ist aber echt klasse.

Normalerweise werden gecachte Apps von Android nach 15 Minuten gekillt, auch wenn der RAM noch komplett leer ist. Der Mod setzt diesen Wert auf 24 Stunden hoch, was echt angenehm ist.
Außerdem kann man mit Android wohl nur 15 Apps gleichzeitig laufen haben, mit dem Mod sind theoretisch 70 möglich.

Link dazu HIER. Natürlich erfolgt alles auf eigene Gefahr und man muss gerootet sein.

Ich nutze ihn selbst und merke einen Unterschied zu vorher. Die Apps bleiben deutlich länger im Speicher, ohne dass das Gerät langsamer wird. Der LMK wird ebenfalls nicht blockiert.

 

[fipsy]

Normalerweise werden gecachte Apps von Android nach 15 Minuten gekillt, auch wenn der RAM noch komplett leer ist. Der Mod setzt diesen Wert auf 24 Stunden hoch, was echt angenehm ist.

Danke für den Hinweis! Das Problem ist, dass die App bei mir schon nach 10 Sekunden raus fliegt. Und das, obwohl der Speicher gar nicht sonderlich voll ist. Offenbar gibt es noch deutlich mehr Kriterien, Apps rauszuschmeißen, als nur deren Größe, die Speicherauslastung und die Zeitdauer der Hintergrundaktivität. Ich benutze sogar 50 MB ext-Cache, was normalerweise problemloses Parallelisieren von ca. 3 großen Apps ermöglicht. Trotzdem wird diese winzige VoIP-App fast immer sofort rausgeworfen, wenn sie in den Hintergrund wandert. Keine Ahnung wieso...