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

[blue8]

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...

Was macht die denn? Wenn sie völlig frei dreht und die CPU dauerhaft auf 100% kickt, während sie im Hintergrund ist, wird sie ziemlich schnell gekillt.
Was hat es mit dem ext-Cache auf sich?
Sag' mir mal bitte den App-Namen, dann probiere ich es mal auf meinem N4

Beste Grüße!

 

[fipsy]

Was macht die denn?

Also mit MobileVOIP kann man vom Handy aus Internettelefonie betreiben. Alternativ aber auch Callback und Callthrough. Ich habe die Endlosschleife beim Callthrough. Und das geht folgendermaßen:

Man wählt in der normalen Telefon-Anwendung eine Nummer und nachdem man die grüne Hörertaste betätigt hat, wählt man einfach MobileVOIP als App für den Anruf aus. Dann wird MobileVOIP gestartet und diese initiiert dann wiederum mit der Telefon-App einen Anruf bei der Callthrough-Nummer.

Hört sich etwas umständlich an, aber so kann man mit einem einzigen Klick aus der normalen Telefon-App über Callthrough für z.B. 0,5 Cent die Minute (www.freevoipdeal.com) in alle Mobilfunknetze telefonieren, wenn man eine Festnetz-Flatrate hat.

Ist das Gespräch beendet, landet man - wie sonst auch - wieder in der Telefon-App (z.B. in der Anrufliste). Das Problem ist nun, dass Android mittlerweile MobileVOIP aus dem Speicher geworfen hat. D.h. betätigt man in der Telefon-App die "Zurück"-Taste am Handy, so wird die Telefon-App beendet und MobileVOIP neu geladen. Da MobileVOIP aber nicht weiß, dass es schon einen Callthrough-Anruf initiiert hat, tut es das erneut. Und so entsteht eine Endlosschleife. Bleibt MobileVOIP hingegen im Speicher, so kommt man nach dem Anruf mit der "Zurück"-Taste wieder zu MobileVOIP zurück und kann dort normal weiter arbeiten (ohne Endlosschleife). Die Endlosschleife wird also durch das Herauswerfen der App aus dem Arbeitsspeicher initiiert.

Ich hoffe, das war einigermaßen verständlich?! *puh*

Wenn sie völlig frei dreht und die CPU dauerhaft auf 100% kickt, während sie im Hintergrund ist, wird sie ziemlich schnell gekillt.

Das ist nicht der Fall. Wenn ich MobileVOIP im Hintergrund laufen habe und CPUStats lade, läuft die CPU regelmäßig auf 125 bis 250 MHz. Also in der niedrigsten, möglichen Taktrate. Daran kanns also nicht liegen.

Was hat es mit dem ext-Cache auf sich?

Sorry! Das war eine bekloppte Bezeichnung von mir. Es ist die dritte Partition auf der SD-Karte, die als Swap-Partition eingerichtet ist. Nicht Cache, sondern Swap wäre die richtige Bezeichnung gewesen! Unter CM7 werden in diese Partition (die bei mir 50 MB groß ist) nicht genutzte Apps ausgelagert, damit sie nicht beendet werden müssen. Also quasi eine virtuelle Speichererweiterung. Auf dem alten Motorola Milestone gibts halt noch nicht so viel Speicher .

Viele Grüße, Volker

 

[satand]

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.

mit dem framework eben nicht
der oom-wert wird auf 0 gesetzt und bleibt auch auf 0...probier es einfach mal aus. mach davor ein backup, dann kann nichts schief gehen.
ich nutze es für mehrere apps, wie den browser, und so wird nun nichts mehr davon geschlossen.

 

[fipsy]

mit dem framework eben nicht
der oom-wert wird auf 0 gesetzt und bleibt auch auf 0...probier es einfach mal aus.

Ähm, ich habe ein Milestone. Der Framework läuft nur mit "ROM based on Android 4.0 or later and an ARM processor". Jaja, ich weiß, das hier ist das Nexus4-Forum . Ich hatte mich aber wegen der oom-Geschichte gemeldet und die geht ja auch auf allen anderen ROMs. Bzw. tut sie das eben nicht.

 

[satand]

Na jut, ich werds wohl mal tun, obwohl ich dafür eigentlich nicht extra den Framework installieren wollte. Zumal ich halt häufig Updates auf neue CM7-Versionen mache und dann jedesmal auch den Framework neu installieren muss. Das ist weniger schön. :-/ Irgendwo habe ich auch gelesen, dass der Framework unter CM7 gar nicht laufen soll. Bin mir da aber jetzt nicht sicher.

du musst nach dem update im framwork-app nur auf "install/update" klicken und neu starten, sonst nichts. kA ob es unter CM7 läuft.

 

[fipsy]

du musst nach dem update im framwork-app nur auf "install/update" klicken und neu starten, sonst nichts. kA ob es unter CM7 läuft.

Ja, ne schöne Sache, wenn man das richtige Phone und OS hat . Ich war / bin halt am Suchen nach einer universell anwendbaren Lösung. Da wäre die Sache mit dem oom sehr schön gewesen. Naja, muss man wohl mit leben, dass es nur für bestimmte Geräte und OS eine Lösung für das Problem gibt .

 

[satand]

läuft es also nicht mit CM7?

 

[fipsy]

läuft es also nicht mit CM7?

Leider nein, weil CM7 ist Android 2.3.x (Gingerbread). Android 4.0 (ICS) entspricht CM9. Siehe hier: CyanogenMod - Wikipedia, the free encyclopedia

Auf CM9 müsste es also laufen, vorausgesetzt das Gerät hat einen ARM Prozessor. Mein Gerät hat einen OMAP Prozessor. Der hat auch einen ARM Core, aber ob er unterstützt wird, weiß ich nicht genau.

 

[fipsy]

Der Vollständigkeit halber möchte ich erwähnen, dass es doch eine Methode gibt, eine Anwendung im Speicher zu halten ohne das Xposed Framework.

Wie satand hier zitiert hat, kann der oom-Wert z.B. auf -17 geändert werden, so dass die App als Systemanwendung gesehen und nicht mehr beendet wird. Wie FieserKiller jedoch richtig bemerkte, hilft ein einmaliges Setzen des oom-Wertes nicht, weil dieser in regelmäßigen Zeitabständen vom System wieder auf den "richtigen" Wert zurückgesetzt wird.

Abhilfe schaffen würde also eine Endlosschleife, die den oom-Wert regelmäßig wieder auf z.B. -17 setzt, solange die Anwendung im Speicher ist. Und genau das scheint zu funktionieren. Ich habe ein Script geschrieben, das z.B. die VoIP-Anwendung jede Sekunde mit oom -17 versieht, solange sie im Speicher ist. Bisher funktioniert dies einwandfrei.

Das entsprechende Script wird z.B. automatisch von der App Tasker gestartet, sobald die "festzunagelnde" Anwendung startet und beendet sich automatisch, sobald die Anwendung aus dem Speicher entfernt wurde.

Das Script sieht dann z.B. so aus:

#!/system/bin/sh

sleep 3
echo "*** START ***" > /mnt/sdcard/.mobilevoip.log
date >> /mnt/sdcard/.mobilevoip.log

while :
do

  sleep 1
  PPID=$(pidof finarea.MobileVoip)
  echo "PPID: $PPID" >> /mnt/sdcard/.mobilevoip.log
  date >> /mnt/sdcard/.mobilevoip.log

  if [ "$PPID" == "" ]
  then
    echo "STOP" >> /mnt/sdcard/.mobilevoip.log
    date >> /mnt/sdcard/.mobilevoip.log 
    break
  fi

  echo "-17" > /proc/$PPID/oom_adj

done

"finarea.MobileVoip" muss natürlich durch den Namen der jeweiligen Anwendung ersetzt werden.

Ergänzung: Wirklich zuverlässig ist diese Methode allerdings auch nicht. Hin und wieder wird die Anwendung trotzdem aus dem Speicher entfernt.

 

[TBM]

Hallo erstmal.
Da hier die App autokiller schon angesprochen wurde wende ich mich einfach mal voller Hoffnung hierher .Und zwar hab ich gestern mit der app mal ein bisschen rumgespielt und sie hat mir nicht sonderlich gut gefallen.Also hab ich sie wieder deinstalliert, allerding OHNE die Werte wieder zurückzusetzen.Dann wollte ich sie nochmal installieren aber dann kam plötzlich die Fehlermeldung "Nicht genügend Speicher" was bei noch 11 GB frei garnicht sein kann. Jetz meine Frage : behält das System die werte auch nach Deinstllation ? Und was hat das jetzt für Auswirkungen, in meinem Fall hatte ich die werte auf das Minimum geschraubt das dort in der Tabelle war.

BITTE UM SCHNELLE RÜCKANTWORT

 

[fipsy]

Oh Mann, warum ist die Google-Suche nur manchmal so schwierig?! Nach Tagen der Sucherei habe ich jetzt endlich die richtigen Suchbegriffe bemüht und bin sofort auf die perfekte Lösung des Problems gestoßen. Ganz einfach und trivial - gewusst wie! Ohne Xposed oder irgendwelche anderen Klimmzüge:

https://www.android-hilfe.de/forum/...s-im-speicher-halten.369184.html#post-5044337

 

[satand]

Oh Mann, warum ist die Google-Suche nur manchmal so schwierig?! Nach Tagen der Sucherei habe ich jetzt endlich die richtigen Suchbegriffe bemüht und bin sofort auf die perfekte Lösung des Problems gestoßen. Ganz einfach und trivial - gewusst wie! Ohne Xposed oder irgendwelche anderen Klimmzüge:

https://www.android-hilfe.de/forum/...s-im-speicher-halten.369184.html#post-5044337

macht xposed etwas anderes?

 

[fipsy]

Da hier die App autokiller schon angesprochen wurde wende ich mich einfach mal voller Hoffnung hierher.

Das hier ist aber der völlig falsche Thread! Bitte stelle deine Frage in einem Thread für Autokiller. Die Suchfunktion hilft hier auch enorm weiter:

Android-Hilfe.de - Suchergebnisse

Der ursprüngliche Beitrag von 13:07 Uhr wurde um 13:09 Uhr ergänzt:

macht xposed etwas anderes?

Keine Ahnung, ich habe mich mit Xposed nie beschäftigt. Aber selbst wenn: Warum Xposed und irgendwelche Packs installieren, wenn man es durch einfaches Bearbeiten der build.prop mit dem Editor bewerkstelligen kann?! Zudem Xposed auf vielen älteren Geräten auch gar nicht läuft.

 

[satand]

Keine Ahnung, ich habe mich mit Xposed nie beschäftigt. Aber selbst wenn: Warum Xposed und irgendwelche Packs installieren, wenn man es durch einfaches Bearbeiten der build.prop mit dem Editor bewerkstelligen kann?! Zudem Xposed auf vielen älteren Geräten auch gar nicht läuft.

da xposed ganz einfach zu bedienen ist und zudem auch einige zusatzfunktionen bietet, die ich nicht mehr missen möchte. vor allem kann man damit auch apps die berechtigungen entziehen und ist dann nicht mehr auf das buggy openpdroid angewiesen.

 

[fipsy]

Klar, dass Xposed noch mehr bietet, habe ich nicht bestritten. Aber wenn es einem nur darum geht, eine App im Speicher zu halten, ist Xposed doch etwas "oversized", oder nicht?

 

[helpitorg]

@satand
Bei Android 7 auf meinem China-Smartphone von Blackview (BV7000 Pro), welches so gut wie gar nicht gebrandet ist, was ansonsten super angenehm ist, war es das "Background auto clean"-Feature, welches ständig die Apps geschlossen hat. Einstellungen -> Arbeitsspeicher -> "Background auto clean...". Siehe Screenshot im Anhang.

Deaktiviert man dies, bleiben alle Apps im allgemeinen bis in alle Ewigkeit, bzw. bis zum nächsten Neustart geöffnet, und bleiben so, wie man sie zuletzt verlassen hat und bis man sie selber schließt.