A13 - Gestartete Apps werden aus dem Speicher geräumt

  • 14 Antworten
  • Letztes Antwortdatum
Netbook

Netbook

Dauer-User
713
Ihr Lieben, ich brauche Hilfe: bin auf meinem Xperia X compact von LineageOS 13 = Android 7.1.2. auf LineageOS 20 / Android 13 umgezogen. War ein Höllenritt und ich habe alle Fehler beim rooten und der Neuinstallation gemacht, die überhaupt möglich sind, aber jetzt läuft es und sehr ordentlich. Bis auf eine Sache: ich war es gewohnt, daß man gestartete Apps wieder aufrufen kann, nachdem man ein oder mehrere andere Apps genutzt hatte und der Wechsel ging meistens Zack Zack, das System hatte die App Seite im Speicher gehalten und man konnte direkt weitermachen. Jetzt aber räumt mir das System die App weitgehend ab, nur die Basisinfo, wo man war, bleibt bestehen, aber die App wird neu geladen und springt dann dorthin wo man war, aber das ist nicht nur lästig, sondern bei einer Öffi-Ticket App (myVRN) auch tödlich - die checkt sofort aus, wenn man sich ein Ticket gekauft hat und es dann wagt, irgendwas anderes aufzurufen. Und wenn man Pech hat werden dann für 100m Fußweg zwei Euro fällig, obwohl man keinen Meter gefahren ist. Und wenn das während der Fahrt passiert steht man ohne Ticket da, dann wird's richtig teuer. Ausprobiert habe ich: die Akkuoptimierung ausschalten (Akkunutzung uneingeschränkt) und die Option, dass bei Nichtnutzung die temp. Dateien etc. abgeräumt werden (App Aktivität bei Nichtnutzung stoppen). Das hat beides *nichts* gebracht, immer noch ist nach dem Umschalten zwischen aktiven Apps fast immer ein Quasi Neustart, halt mit Sprung zur letzten aktiven Seite, fällig. Hat irgendwer dasselbe Problem (gehabt) und weiß eine Lösung? Freier Speicher sollte genug da sein, immer zwischen 700 MB und 1,1 GB...
 
Zuletzt bearbeitet:
Netbook schrieb:
Freier Speicher sollte genug da sein, immer zwischen 700 MB und 1,1 GB...
Das ist ja fast nichts.
Voll ist der im Normalbetrieb ja nie, das ist so etwas da Minimum was Android frei räumt.

Das Gerät ist einfach komplett veraltet.
Technisch und dadurch für neuere Android Versionen viel zu schwach.
 
  • Danke
Reaktionen: kurhaus_
Das mag ja sein, aber ich finde, bei einem GB freien Speicher könnte man schon ein paar Seiten im Speicher halten, so viel Platz kann da nicht kosten. Unter 7.1.2 ging das alles problemlos, obwohl das zum Teil deutlich weniger Speicher frei war. Und das ist, wie man hier im A13er Forum liest, ja nicht die einzige Merkwürdigkeit (verstellte Einstellungen etc.). Und die maximale Anzahl von Hintergrundprozessen habe ich schon von Standard (=???) auf 5 gesetzt (Entwickleroptionen)....

Oh, über Nacht hat sich was getan: habe neben diesem noch vier Apps offen und zumindest drei bleiben offenbar im Speicher, sind sofort da. Was ist anders: die genannte Option und ich habe über Nacht die "Don't kill my Apps" App laufen lassen. Die hat heute morgen 100% gezeigt. Hmm. Alles seltsam, aber ich will nicht meckern. Jetzt wäre gut, wenn es einen ADB Befehl gäbe, der mir erlaubt aus 5 dann 7 Hintergrundprozesse zu machen, denn ein paar sind leider unvermeidlich (Playstore, SD-Maid, Macrodroid...), wobei mir unklar ist, ob z.b.der Playstore dazu gezählt wird. Den kann man ja wg gekaufter Apps leider nicht temporär deaktivieren 🙄
 
Zuletzt bearbeitet:
Netbook schrieb:
Jetzt wäre gut, wenn es einen ADB Befehl gäbe, der mir erlaubt aus 5 dann 7 Hintergrundprozesse zu machen
Nie ändert das nichts.
Android wird den RAM weiterhin zu gewissen Teil frei halten.
 
  • Danke
Reaktionen: kurhaus_ und Netbook
maik005 schrieb:
Android wird den RAM weiterhin zu gewissen Teil frei halten
leider hast du recht, der schöne Effekt ist auch schon wieder verschwunden, jetzt wird wieder abgeräumt.
 
maik005 schrieb:
Das Gerät ist einfach komplett veraltet.
Technisch und dadurch für neuere Android Versionen viel zu schwach.
Alt? Ja 😄! Veraltet? Wenn ich einen Backstein mit mir rumtragen will, kaufe ich mir ein neues Smartphone, denn diesen "veralteten" Formfaktor gibt's so gut wie gar nicht mehr, iPhone SE vllt...
Und das "Problem" ist eindeutig Android 13 bzw. die LOS20 Version. Bin zurück auf Android 9 (kein verdam.... scoped storage!) und alles läuft butterweich, Dutzende von geöffneten Apps, die sofort aufspringen, wenn man sie in der Übersicht anwählt, und diese Übersicht übersteht sogar einen Boot. Ich bin sicher, 13 kann das auch, aber eben nicht LOS20, und das hat offenbar nichts mit dem Speicher zu tun. Veraltet? Keine Ahnung, für heftige grafische Spiele vielleicht, ansonsten top fit alles, was ich brauche, Browser, WhatsApp, YouTube, Telegram, Notizen, Kalender etc. Und alles funktioniert, (BT vor allem, hat unter 7.1.2 den Akku gefressen) und mit <2% im normalen Standby auch nicht schlechter als andere. DOT ca. 5h, damit kann ich gut leben 😀
Bin wieder happy und habe noch eine Empfehlung (aber root): AppBackup (war früher BuggyBackup), deutlich besser als Tit+ pro, gibt's aber nur noch im Telegram-Kanal von Buggysoft (ist angepinnt).
 
Zuletzt bearbeitet:
Netbook schrieb:
und diese Übersicht übersteht sogar einen Boot.
Das kann nicht sein. RAM ist ein Speicher, der ohne Strom sofort geleert wird. Vielleicht ist die Übersicht noch da, aber die Apps starten komplett neu.

Netbook schrieb:
Freier Speicher sollte genug da sein, immer zwischen 700 MB und 1,1 GB...
Laut Google hast du 3GB gesamt. Android hält immer ca. 35-30% des RAM frei, um Spitzen abzufangen. Das entspricht exakt ca. 1GB. Also ist soweit alles normal bei dir.

Dein Problem ist ganz einfach, dass du insgesamt zu wenig RAM hast. Hinzu kommt, dass LOS nun mal nicht perfekt an jedes Modell angepasst wird und deswegen auch nie perfekt läuft.
 
  • Danke
Reaktionen: maik005
Klaus986 schrieb:
Das kann nicht sein. RAM ist ein Speicher, der ohne Strom sofort geleert wird. Vielleicht ist die Übersicht noch da, aber die Apps starten komplett neu.
Etwas anderes habe ich auch nicht behauptet. Ist übrigens egal, ob Reboot oder komplettes ausschalten. Vom Neustart der Apps merkt man praktisch nix und sie setzen auch genau da auf, wo sie waren. Das alles war unter 13 (LOS 20) ganz anders, wenn überhaupt noch ein Eintrag da war, dann war die page leer und die App ist sekundenlang neu hochgefahren, auch ohne boot, wenn 13 (LOS 20) meinte, seinen Speicher frei räumen zu müssen.
Klaus986 schrieb:
Laut Google hast du 3GB gesamt. Android hält immer ca. 35-30% des RAM frei, um Spitzen abzufangen. Das entspricht exakt ca. 1GB. Also ist soweit alles normal bei dir.
So ist es. Aber Android macht das sehr dynamisch und Du darfst Zram nicht vergessen. Nein, 3 GB geht durchaus, aber nicht mit LOS 20 und der aggressiven Freiräumerei. Unter 9 habe ich genauso wenig freien Speicher wie unter 13, aber da klappt alles.
Klaus986 schrieb:
Dein Problem ist ganz einfach, dass du insgesamt zu wenig RAM hast. Hinzu kommt, dass LOS nun mal nicht perfekt an jedes Modell angepasst wird und deswegen auch nie perfekt läuft.

LOS 20 von Chippa_a ist ausdrücklich für das X compact.
 
Zuletzt bearbeitet:
Netbook schrieb:
LOS 20 von Chippa_a ist ausdrücklich für das X compact.
Ja, natürlich muss das für ein bestimmtes Modell kompiliert werden. Du musst ja den Device Tree berücksichtigen. Aber deswegen ist es immer noch nicht mit einer perfekt zugeschnittenen Firmware vergleichbar. LOS ist ein Overlay und keine Firmware.

Netbook schrieb:
Nein, 3 GB geht durchaus,
Ja, mit veralteter Firmware sind auch 3GB noch irgendwie ok. Aber wie du selbst merkst, ist es nicht für aktuelle Systeme geeignet.
 
  • Danke
Reaktionen: maik005
Netbook schrieb:
Du darfst Zram nicht vergessen.
der kaum relevant ist, schon gar nicht bei so wenig RAM.
Denn zRAM ist auch nur Teil des RAM, wird also von diesem noch mal abgezogen.

Netbook schrieb:
Nein, 3 GB geht durchaus, aber nicht mit LOS 20 und der aggressiven Freiräumerei. Unter 9 habe ich genauso wenig freien Speicher wie unter 13, aber da klappt alles.
kannst oder willst du nicht verstehen, dass 3 GB einfach viel zu wenig sind für ein ansatzweise aktuelles Android? :sneaky:
Nimm in der Theorie Android 4 und das Teil würde mit den 3 GB super laufen (veraltete Apps und andere Probleme aufgrund des Alters der Android Version mal ausgeblendet)
 
  • Danke
Reaktionen: Klaus986
Klaus986 schrieb:
Aber deswegen ist es immer noch nicht mit einer perfekt zugeschnittenen Firmware vergleichbar. LOS ist ein Overlay und keine Firmware.
Wie kommst Du denn darauf? Firmware auf dem PC war natürlich das BIOS, das z.B. die Festplatten verwaltet hat etc., das Betriebssystem war halt das Betriebssystem. Bei Android ist das insofern anders, als auch das Betriebssystem geflashed wird (wie sich im Namen Custom "ROM" wiederspiegelt) und deshalb auch gerne als Firmware bezeichnet wird. Man könnte ansatzweise den Kernel als unterste Schicht mit dem Bios vergleichen, weil zum einen auch der Kernel die Hardwarezugriffe für alles regelt bzw. bereitstellt und andererseits mehrere Versionen des Betriebssystems mit demselben Kernel laufen (bis 9.0 war das wohl der 3.x, ab da dann der 4.x). Und das ist insofern interessant, als die Google Pixel Camera Software (LMC 8.4) nicht mit dem Kernel 3.x läuft und andererseits laut Aussagen von Chippa_a sich auch nicht mit Android-Versionen < 10 kompilieren lässt. Und mit der LMC8.4 unter LOS20/A13 konnte das XC sogar Dinge, die es eigentlich nicht können sollte, Video-AntiVerwacklung etc. Klar, da hat der alte Snapdragon des XC ganz schön geschnauft und Feuer gespieen, sprich ist warm geworden, aber immerhin, es ging.
Nein LOS20 ist sicher kein "Overlay", sondern einfach ein AOSP-Android, sprich ein OS, ein Betriebssystem, weswegen es ja auch LineageOS heisst. Lineage, weil es quasi von den CyanogenMod custom ROMs "abstammt".
Die größten Änderungen zwischen A9 und A10-A13 betreffen etwas, das zwar die Perfomance ganz erheblich ausbremsen kann, aber mit der Hauptspeicherverwaltung nur indirekt zu tun hat: scoped storage. Das dient dem Schutz von "privaten" App-Daten gegenüber dem Auslesen durch andere Apps und wurde bei A10 halbherzig und versuchsweise eingeführt, ist aber über 11 und 12 auf 13 zwingend geworden. Damit einher gehen extreme Performanceverluste beim Lesen, Schreiben und Löschen von Dateien durch Apps, Zitat:

(Quelle: Analyse der Sicherheit und Performance von Scoped Storage unter Android)

Zur Verbesserung der Privatsphäre sollte Scoped Storage im Wesentlichen eine Sandbox für
Applikationsdaten einführen, sodass Dateien nur noch geteilt werden können, die (a) zu einer definierten
Kategorie von Mediendaten gehören, oder (b) vom Nutzer explizit für die Verarbeitung in einer
bestimmten App vorgesehen wurden.

Beim Studium der Implementierung fällt auf, dass für jeden File-System-Zugriff über die File-API mehrere
rechenintensive Operationen ausgeführt werden müssen. Aus der App heraus wird die Ausführung
zunächst wie üblich per Syscall an den Kernel übergeben. Von hier wird über das FUSE-Kernel-Modul der
FUSE Daemon aufgerufen. Dieser wiederum greift mittels Java Native Interface (JNI) auf den eigentlichen
Media Store zu, von wo erst eine SQLite-Datenbank und das zugrundeliegende Dateisystem befragt
werden. Aus der Summe dieses komplexen Zusammenspiels verschiedener Komponenten ergibt sich ein
nicht unerheblicher Performance-Overhead, wenn die FUSE-Übersetzungsschicht genutzt wird.

Für jedes Experiment wurde der Mittelwert aus 10 Samples ermittelt. Es wurde ein Google Pixel 3 mit
Android 11 verwendet.
Wie in der untenstehenden Grafik ersichtlich zeigte sich, dass wie erwartet das Schreiben per direktem
Filesystem-Zugriff am schnellsten war. Die MediaStore-Schnittstelle zeigte sich gut 5x langsamer (502%),
war aber dennoch schneller als FUSE-Zugriff. Letzterer war fast 6x langsamer als der direkte Zugriff (583
%). Beim Lesezugriff waren die Unterschiede sogar noch deutlich größer (MediaStore: 658% overhead,
FUSE: 1053%). Die größten Unterschiede zeigten sich beim Löschen der Dateien: MediaStore war 36x
(35505%) langsamer als direkter Zugriff, FUSE 33x (32715%).
Hier schnitt die MediaStore-API
interessanterweise knapp schlechter ab als FUSE.
(Hervorhebung durch mich)

Ich kann zwar nicht behaupoten, daß davon gar nichts zu bemerken gewesen wäre, aber das hielt sich durchaus in erträglichen Grenzen, die man auf einem alten Smartphone zu akzeptieren bereit ist. Damit allerdings gar nichts zu tun hat die Verwaltung des Appspeichers, bei der ganz offenbar ein sehr viel aggressiveres Vorgehen des LMK implementiert wurde. Da ich identische Apps unter LOS16/A9 und LOS20/A13 verwende und natürlich den Speicher unter beiden OS beobachte, kann ich definitiv sagen, daß unter LOS20 Apps abgeräumt werden, wenn noch völlig ausreichend Platz ist. Ich kann aber nicht mit Bestimmheit sagen, daß dies an A13 liegt, es könnte genauso gut eine LOS20 Implementation mit unpassenden LMK-Werten sein, denn es ist absolut kein Grund ersichtlich, warum ein und diesselbe App unter 13 mehr Platz brauchen sollte als unter 9. Und wie gesagt, alle Apps, die ich nutze, liefen identisch unter beiden OS-Versionen. Ja, das OS in der Version 13 beansprucht ein wenig mehr Speicher, aber das kann als Grund für das Vorgehen des LMK nicht herhalten, schon eher, daß er sehr viel schneller die OOM-Werte von Apps nach oben über die 900 schiebt (Minus-Werte sind für System-Apps, die nicht gekilled werden sollen, eine neu gestartete App startet z.B. mit +100, bekommt aber schnell ein +700, wenn die nächste App startet, und mit der dritten dann ev. ein 900+x und dann ist der Kill angesagt). Ich habe versucht mit Bash-Befehlen die OOM-Werte zur Laufzeit zu korrigieren, was nicht geklappt hat, weil seit Android 10 alles mögliche in Bezug auf den LMKD geändert wurde (Low memory killer daemon | Android Open Source Project) und möglicherweise die PSI monitors mit der LOS20 Implementation für das XC unverträglich sind. Und nein, Ihr müsst mich nicht belehren, daß ich ein altes Phone mit wenig Speicher nutze, das weiß ich selbst. Und wer mir erklären will, daß ich den Z-Space davon ja noch abziehen muss - naja, dazu sage ich besser nix :)
Noch eine Bemerkung zu "scoped storage": Bis 9 konnte man mit der wirklich nützlichen App SD Maid einiges Auf- und Abräumen (Installationsreste etc.), aber vor allem auch den Apps, die man nur sporadisch braucht, den Autostart entziehen - und zwar ohne sie komplett zu deaktivieren. Das macht die App im Tagesbetrieb ja unbrauchbar, gilt aber z.B. bei heise noch 2023 als heisser Tipp. Wie gesagt, mit der SD Maid konnte man die diversen Autostart-Trigger (bis zu einem Dutzend, aber manche App nur ein bis zwei) deaktivieren, und das hat den Systemstart ganz erheblich entlastet bzw beschleunigt. Dass dann im Tagesbetrieb eine selten genutzte App minimal langsamer startet, ist wirklich egal - und natürlich entzieht man wichtigen Apps (Kalender, Messenger etc.) den Autostart *nicht*. Aber diese Möglichkeit scheint Google abgeklemmt zu haben, die neue SD Maid SE kann das nicht mehr, braucht aber für Standardaufgaben, wohl wg des "scoped storage" Systems , jetzt ewig. Natürlich kann man diese Systembremsen mit entprechend Rechenpower ausgleichen und es ist kein Wunder, daß moderne Phones, die Faktor 10-20 mal schneller sind als meins, davon nicht viel bemerken. Aber insgesamt kommt mir das so vor wie damals beim Sprung von DOS 3.11 auf 4.01: völlig überladen, ruckelig und langsam. Und nach etwas Warten kam dann 5.0 und es war schlank und schnell. Vielleicht passiert das auch mit Android, aber andererseits würde ja dann viel Druck aus dem Markt genommen, wenn ein modernes Android noch auf alter Hardware performant laufen würde ;-) Und ja klar, ich komme noch als den alten Zeiten, in denen Rootzugriff so selbstverständlich war, daß niemand das groß thematisiert hat und solche Fesseln, wie sie einem Android mittlerweile anlegt, als mittelschwere Beleidigung und Grund, sich einem anderen System zuzuwenden, gegolten hätten.
 
Netbook schrieb:
Und wer mir erklären will, daß ich den Z-Space davon ja noch abziehen muss - naja, dazu sage ich besser nix :)
Besser ist das wohl.
Du schreibst eh schon viel zu viel ;)
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: Klaus986 und swa00
Netbook schrieb:
Wie kommst Du denn darauf?
Weil es so ist :1f602: Du kannst dir gerne eine beliebige ROM von LOS runterladen und sie entpacken. Dann vergleichst du diese Images mit einer kompletten Firmware.

Netbook schrieb:
Man könnte ansatzweise den Kernel als unterste Schicht mit dem Bios vergleichen,
Kannst du gerne machen, ist aber falsch. Wenn du auf dieser Ebene einen Vergleich machen willst, nimm bitte den Bootloader und nicht das boot.img.
 
  • Danke
Reaktionen: maik005 und swa00
@Netbook

nachdem man ein oder mehrere andere Apps genutzt hatte und der Wechsel ging meistens Zack Zack, das System hatte die App Seite im Speicher gehalten und man konnte direkt weitermachen. Jetzt aber räumt mir das System die App weitgehend ab, nur die Basisinfo, wo man war, bleibt bestehen, aber die App wird neu geladen und springt dann dorthin wo man war,

Schau dir dazu bitte erst einmal die LifeCycle Funktionsweise von Android an (AMS).
Dann verstehst du auch besser, wo eine App an welcher Stelle genau inne hält und wann es wie weiter geht (und muss), wenn sie in den Vordergrund kommt.

Insbesondere für Dein Verständnis zum Speicher-Management
 
Zuletzt bearbeitet:
@Netbook Womit genau bist du jetzt eigentlich unzufrieden? Dein Gerät ist 9 Jahre alt und war niemals dazu konzipiert A13 und die damit einhergehenden Neuerungen wie Scoped Storage zu nutzen. Dein RAM ist auch nicht darauf ausgelegt. Sei doch einfach froh, dass du A13 darauf nutzen kannst und vertiefe dich nicht in m.M.n. sinnlosen Benchmarks deines Handys. Die Probleme, die du hast, sind doch eindeutig auf deine Hardware zurückzuführen und spielen bei Geräten, die mit A13 ausgeliefert wurden gar keine Rolle.
Beiträge automatisch zusammengeführt:

Netbook schrieb:
Nein LOS20 ist sicher kein "Overlay",
Funktioniert dein NFC? Gibt es irgendein Modell älter als 5 Jahre, auf welchem LOS ohne Bugs läuft? LOS klatscht alle nötigen Dateien über deine Firmware drüber, um es auf eine aktuelle Version von Android zu pimpen. Nicht mehr und nicht weniger. Von einem vernünftigen Betriebssystem erwarte ich ein voll funktionsfähiges Gerät. Das biete dir LOS nicht.
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: MvBoe, maik005 und swa00
Zurück
Oben Unten