Browser killt Applikation

[feinfinger]

Hallo,

ich habe mit meinem selbsgebastelten Ortungstool ein interessantes Phänomen, es sieht so aus als ob manche Internetseiten mein kleines Programm,welches im Hintergrund läuft, einfach ungefragt beenden. Trotz großzügiger Vergabe von Try/Catch Blöcken bekomme ich keinerlei Fehlermeldung dabei zurück!? Ich habe auch bereits die einzelnen Bereiche wie Gps oder Netzwerk einfach mal aus der Initialsierung in meinem Programm rausgenommen und habe das Problem immer noch!

Falls jemand weis aus welcher Richtung hier das problem kommt wäre ich für Hilfe sehr dankbar!

Gruß
Feinfinger

 

[Markus]

Das Android OS kann jederzeit Apps killen wenn es denkt dass es sinnvoll wäre, z.B. um Speicher freizumachen. Sicherer ist es auf Services anstatt auf Activities zu setzten. Android versucht dann so gut es geht einen Service laufen zu lassen.

 

[magnummandel]

Und Android macht das gerne und oft. Ihr müsst mal bei verschiedenen apps einstellen, dass Meldungen erscheinen wenn sie gestartet oder beendet werden. Ja nachdem was ich gerade treibe kommen bei mir von den wildesten Apps die Meldungen, dass sie gerade wieder gestartet wurden.

 

[GMoN]

Gibt es irgendwo eine gute Erklärung, wie das mit diesen Background Services läuft, evtl mit kleinem Beispiel? Services haben doch keine GUI aber die brauche ich für meineApp.

 

[feinfinger]

Danke für die Hinweise, ich hab mich auch gleich mal an den Service gemacht anhand von diesem Bsp:
developerlife - Tutorials Android Service creation and consumption

 

[enjoy_android]

Zu dem Thema sei auch noch zu sagen das sich Services selbst wieder neu starten. Man kann den Unterschied zwischen einem Neustart und ersten Start des Services über die Abfolge der aufgerufenen Callback Methoden identifizieren. Beim ersten Start des Services wird "onCreate + onStart" aufgerufen, beim Restart nach einem Crash wird nur "onStart" aufgerufen.

Du fragst auch nach einem UI. Starte das UI (die Activity) einfach von deinem Service aus, wenn er nötig wird.

PS: Services sind nicht allzu schwierig umzusetzen also nur zu ausprobieren.

 

[GMoN]

Hmm, dass ist echt übel. Der Browser killt auch meine Anwendung und zwar jedes Mal Und dummerweise läßt mir Android dann keine Zeit zum speichern.

Den Back Button habe ich jetzt so abgefangen, dass ich erst in Ruhe speichern kann und erst danach wird der Key an Android weiter gereicht. Aber hier bei bin ich machtlos. Ein Service würde mir wahrscheinlich auch nicht helfen, denn auch die können und werden ja von Android gekillt und meine App braucht nun mal massig Speicher . Würde ja auch nichts bringen, in onPause das Speichern in nen Thread zu schicken oder würde der Thread unabhänging solange weiter existieren,bis zu Ende gespeichert wurde? Aber die Arraylist, die ich speichern muss, hat das System dann eh schon vorher platt gemacht....

Das ist auch wohl das Problem, dass die ganzen IMs noch Probleme haben, connected zu bleiben. Bei Symbian konnten auch Programme bei Speichermangel vom System geschlossen werden, allerdings konnte man Programme als Systemprogramme deklarieren und dann ließ Symbian die Finger davon. Dann kam halt ne Meldung "Speicher voll, bitte Programme schließen um neue zu starten" und der User konnte selbst entscheiden, welches Programm er schließen möchte.

Aber hier wird der User verarscht. Der meint, oh geil, ich kann 100 Programme starten, ohne dass der Speicher knapp wird. Nur laufen von diesen 100 nur 2, der Rest ist tot. Super, 5 Stunden WarWalken gewesen und aus Versehen den Browser gestartet und kein einziges WLAn wurde gescannt. Ein sehr zuverlässiges BS ist Android somit nicht gerade.

Ich werde den Service sicherlich noch mal probieren, wenn ich das mal genauer blicke aber derzeit muss ich erst das Speichermangelproblem lösen, allerdings verspreche ich mir für meine App eigentlich nix davon.

 

[enjoy_android]

Naja so ganz schwarz wie du es malst ist es nicht. Ich habe mit meiner App auch nen Background Service laufen und da er von Android selber automatisch wieder gestartet wird (passiert ca. 10 mal am Tag - mit vielleicht max 1s Downtime), habe ich nicht wirklich Probleme damit.

Nur Anwendungen die den Background Service falsch implementieren haben Probleme damit. Bei Musikanwendungen ist das neustarten durch eine kurze Unterbrechung der Musik zu hören.

Des weiteren kann ich dir sagen das mit 1.5 die Browserprobleme so gut wie behoben sind.

Im Endeffekt hast du nun mal nur so viel Speicher wie das Gerät zur Verfügung hat. Wenn dieser alle ist hast du egal bei welchem Mechanismus immer ein Problem. Zu deiner Anwendung kann ich nur sagen, speichere den Status so oft es geht und nicht erst am Ende. (das gilt vor allem für Background Services)

 

[Manfred]

Ist es möglich es irgendwie mitzuloggen ob das service neu gestartet wurde?

 

[GMoN]

Nochmal die Frage ob Android mit dem Schließen der Anwendungen wirklich so lange wartet, bis onPause komplett abgearbeitet wurde, wenn es nicht das Timeout von 5(?) Sekunden überschreitet? Also wenn mein Speichern nur 1 Sekunde dauern würde, würde das auch komplett gemacht? Irgendwie habe ich den Eindruck, dass sofort alles abgebrochen wird, was was auch nur ansatzweise den Thread blockiert, egal wie lange in diesen OnPause(), OnStop() und onDestroy().

Und an welcher Stelle im OnPause() setze ich denn super.onPause()? Vor oder nach meiner Speichermethode? Habe da schon verschiedene Beispiele gesehen, mal stehts am Anfang, mal am Ende. Vielleicht liegt da auch mein Problem

Ich denke, das Speichern kann ich noch auf deutlich unter einer Sekunde verkürzen, wenn ich nur die neuen Daten speichere und die dann beim nächsten Start mit den alten Daten synchronisiere. Wenn das klappt, müßte es schon wieder besser aussehen

 

[enjoy_android]

Ist es möglich es irgendwie mitzuloggen ob das service neu gestartet wurde?

Ja das ist möglich. Sobald nur "onStart" in deinem Service aufgerufen wurde setzt du einen Int Wert in den SharedPreferences hoch. Somit kannst du schön auslesen wie oft das passiert. (das wäre die einfachste Möglichkeit die mir eben spontan eingefallen ist)