1. Möchtest Du unser Team im Android OS-Bereich unterstützen? Details dazu findest du hier!
  2. Nimm jetzt an unserem Uhans - 3. ADVENT - Gewinnspiel teil - Alle Informationen findest Du hier!

App2SD - Komplett-Überblick verschiedener Methoden

Dieses Thema im Forum "Sonstige Apps & Widgets" wurde erstellt von michael_and, 12.09.2011.

Status des Themas:
Es sind keine weiteren Antworten möglich.
  1. michael_and, 12.09.2011 #1
    michael_and

    michael_and Threadstarter Erfahrener Benutzer

    Beiträge:
    165
    Erhaltene Danke:
    58
    Registriert seit:
    12.12.2010
    Alles über die verschiedenen Methoden, um internen Speicherplatz frei zu machen
    == Überbegriff: "App to SD" ==

    Dieser Artikel soll etwas Klarheit bringen in die Welt von "App to SD".

    Nach Lesen in diversen Foren war ich zunächst irritiert, und habe mir dann nach und nach ein Bild vom Thema gemacht, das ich hiermit zusammenfassen und teilen möchte.

    Fragen, die ich hier beantworten möchte:
    • Wozu das Ganze / Wer braucht das?
    • Was bedeuten Move2SD, App2SD, A2SD, A2SD+, DT A2SD, DT App2SD, Link2SD, ...?
    • Was sind die Unterschiede/Gemeinsamkeiten der verschiedenen Methoden?
    • Welche Methode geht für welche Android-Version?
    • Für welche Methode muss ich ein "rooted" Smartphone haben?
    • Für welche Methode brauche ich eine speziell partitionierte SD-Karte?
    • Welche Methode geht für welche Apps?
    • Kann man die Methoden miteinander kombinieren, und ist das sinnvoll?
    • Warum wird der interne Speicher trotzdem immer voller, obwohl ich App2SD hab?

    Sollte ich irgendwo Fehler haben oder sollte es was zu ergänzen geben, sind Hinweise natürlich sehr willkommen. Ich werde dann versuchen, die Korrekturen in diesen Beitrag einzuarbeiten.

    Also, eins nach dem anderen...

    Wozu das Ganze / Wer braucht das?
    Android Smartphones installieren Apps standardmäßig im internen Speicher (für's Datenblatt: Achte auch "interner Speicher (ROM), NICHT auf RAM). Der ist oft begrenzt, oft sind nur rund 100-200 MB frei, wenn man das App neu kauft. Wenn man viele Aps installiert (mit der Zeit können locker über 100 Apps zusammen kommen, oft auch über 200), ist der Speicher bald voll. Zwar brauchen Apps oft nur um die 200 kB Speicher, viele brauchen aber auch 1 MB, 3 MB, 6 MB oder manchmal auch 10 oder 20 oder mehr MBytes. Ist der Speicher voll, kann man keine weiteren Apps mehr installieren, oder muss erst wieder welche deinstallieren. Das ist schlecht! Android warnt meist, wenn nur noch ca. 20 MB frei sind, und dann gibt's auch schon oft Probleme, z.B. dass keine SMS mehr gespeichert werden kann.

    Also haben sich die Androiden gedacht: Wie wäre es eigentlich, Apps auf der Speciherkarte zu installieren, die ist doch große genug! Genau!

    Jetzt mehr Details:
    Wenn ich eine App installiere und benutze, dann wird der folgende Speicher belegt, bei dem es sich um eine Partition im internen Telefonspeicher handelt:

    (1) /data/app/<Dateiname>.apk
    (2) /data/dalvik-cache/<Dateiname_der_App>.dex
    (3) /data/data/<Verzeichnisname_der_App>/lib/<Dateiname>.so
    (4) /data/data/<Verzeichnisname_der_App>/<sonstige Dateien und Verzeichnisse>

    (Seitenbemerkung.: System Apps (im Gegensatz zu installierten Apps) befinden sich auf einer eigenen internen Partition unter /system/app/)

    Was ist das alles genau? Nun:

    • (1)=Die heruntergeladene App
      --> Größe: wird im Android Market angezeigt
    • (2)=Eine aus (1) vom Betriebssystem generierte ausführbare Datei. Bem.: Wenn sie gelöscht wird, stellt das Betriebssystem sie aus der *.apk-Datei (1) wieder her, ist also nicht schlimm, bringt aber auch nichts, außer man löscht eine dalvik-cache-Datei, zu der es gar keine *.apk-Datei mehr gibt, also "Datenmüll", den es bei sauberer De-Installation aber eigentlich nicht geben darf. Wenn man auf ein App-Symbol tippt um eine App zu starten, dann greift das Betriebssystem auf diese dalvik-Datei zu, und NICHT auf die *.apk-Datei aus "(1)".
      --> Größe: ähnlich wie die *.apk Datei, in der Regel etwas kleiner, kann variieren
    • (3)=library Dateien, sind bei einigen (vielen) Apps gar nicht vorhanden, können manchmal aber auch ziemlich groß sein
    • (4)=Sonstige App-spezifischen Daten. Datenmenge unterschiedlich, im Allgemeinen eher gering (Ausnahme z.B. Browser cache...)
    Man sieht also: Wenn man (1), (2), (3) und (4) auf die SD-Karte "verschieben" würde, wäre der interne Speicher komplett entlastet. Bei den meisten heute üblichen Methoden wird aber nur ein TEIL davon auf die SD-Karte verschoben, oft nur (1). Details im Folgenden...


    Die Details
    Es gibt unterschiedliche Methoden, WAS von (1), (2), (3) und (4) auf die SD-Karte verschoben wird, und WIE das passiert.
    Generell gibt es drei Gruppen von Methoden:

    Methode A (kurz: "natives App2SD von Google"):
    (z.B. App 2 SD, Move 2 SD)
    • ab Android 2.2=Froyo
    • kein "root" benötigt
    • keine zweite SD-Karten-Partition benötigt
    • Auswahl auf "per App" Basis möglich
    • Viele Apps lassen sich aber gar nicht verschieben mit dieser Methode
    • Nur (1) wird verschoben (nur das *.apk file der jew. App)
    Beschreibung:
    Man kann pro selbst installierter App entscheiden, ob man diese auf die SD-Karte verschieben möchte. Das geht auch nachträglich, und es geht "hin" und "zurück" nach Belieben. Was dann passiert ist, dass die *.apk Datei nach "/sdcard/.android-secure/" (="/mnt/secure/asec/") verschoben wird [evtl. irgendwie verschlüsselt?] (Bem.: Außerdem entsteht der mount point "/mnt/asec/<dateiname>/", wo sich die ausgelagerte apk Datei im Klartext befindet). Mit einem Datei-Browser wie z.B. Adao File Manager aus dem Market kann man das überprüfen (oder mit rootexplorer). Das Betriebssystem (ab 2.2) unterstützt dieses Feature nativ, darum ist diese Methode für Android 2.1 und früher nicht möglich.

    Einschränkungen:
    - Geht nur für einige Apps, die so programmiert sind, dass sie "App2SD" im Sinne dieser "Methode A" (Android 2.2+ native) unterstützen. Z.B. fallen wohl Widgets generell nicht darunter, aber auch viele andere Apps unerstützen dies nicht, wenn der Programmierer es nicht vorgesehen hat.
    - Geht grundsätzlich nicht für System-Apps (also vorinstallierte und nicht de-installierbare Apps).

    Diese Methode ist also Bestandteil des Betriebssystems, und es gibt verschiedene grafische Front-Ends, die einem die Arbeit für's Hin- und Herschieben erleichtern, z.B. die App "Move2SD" aus dem Android Market.

    Methode B (kurz: Symbolic Links auf Verzeichniss(e) auf der SD-Karte):
    (A2SD, A2SD+, DT A2SD, DT Apps2SD, ...):
    ...und oft auch mit "App2SD" bezeichnet (auch von App-Autoren), um die Verwechslung und Konfusion mit Methode A komplett zu machen.
    • ab Android 1.6 (oder sogar schon früher? - naja älteres Android hat hier eh niemand...)
    • "root" benötigt!
    • Zweite SD-Karten-Partition benötigt! (als zweite Partition nach der FAT32-Partition, aber auch als primary(!) Partition einrichten, und zwar als ext2/ext3/ext4 (ja nachdem, was dein Smartphone-System (ROM) unterstützt))
    • Auswahl auf "per App" Basis NICHT möglich (nur für "alle oder keine" Apps [nicht-system-apps])
    • Ob die zu verschiebende App ein "App2SD" gemäß "Methode A" unterstützt oder nicht, ist irrelevant.
    • Bei A2SD wird nur (1) verschoben (nur das *.apk file), bei neueren Varianten wie A2SD+ oder "Dark Tremor Apps2SD" kann auch zusätzlich noch wahlweise der dalvik-cache (2) und auch (3)+(4) (letzteres nut gemenisam) auf die SD-Karte verschoben werden (aber nicht App-spezifisch).
    Beschreibung:
    Man muss das Feature in der Regel über Recovery (= Bootmenü, wie das BIOS, suche z.B. nach "Clockwork Recovery", "ClockworkMod Recovery", "CWM Recovery") einspielen. Bei den meisten Custom ROMS ist es schon drauf. Was dann passiert ist, dass nach Booten des Systems das Betriebssystem die zweite Partition der SD-Karte erkennt und ins Dateisystem einhängt (mountet), und zwar unter "/system/sd/".
    Damit ist aber noch nichts passiert, die App-Dateien sind immer noch im internen Speicher. Aber jetzt kommt der schlaue Trick, Linux macht's möglich:
    Wenn man nun über eine geeignete grafische Oberfläche das Verschieben der Apps von Intern nach SD-Karte veranlasst, dann passiert im Hinitergrund im System Folgendes:
    Es werden die Daten von /data/app/ nach /system/sd/ verschoben, also physikalisch auf die SD-Karte verlagert. Dann wird ein symbolischer link erzeugt, der von /data/app/ nach /system/sd/app/ zeigt. Das ist alles. Auf diese Weise kann das Betriebssystem wie gewohnt auf "/data/app/<Dateiname>.apk" zugreifen und merkt gar nicht, dass diese Datei auf der SD-Karte liegt, bzw. es ist ihm "egal". Alle Betriebssystem-Operationen können also wie üblich ablaufen, die Änderung ist für das Betriebssystem völlig transparent, und darum geht es auch für Android 1.6 oder 2.1.

    Auf die gleiche Weise kann man auch den dalvik-cache auf die SD-Karte "umleiten" (A2SD+, "Darktremor A2SD" (DT A2SD), "Darktremor App2SD", ...). Ein Beispiel eines grafischen User-Interfaces ist die App "A2SDGUI for Darktremor A2SD" (Google Market), womit man (1) (apk) oder (2) (dalvik-cache) von intern nach SD aktivieren und deaktivieren kann.
    [Das Umbiegen von System-Apps geht GLAUBE ich nicht, oder nur mit speziellen Lösungen dann vielleicht doch, ist jetzt aber hier nicht der Schwerpunkt, weil für die allermeisten Fälle wirklich nicht relevant.]
    [Bem. zu A2SDGUI: Diese App (in Verbindung mit "Darktremor Apps2SD") kann noch viel mehr als nur A2SD, nämlich System-Interna auf vielerlei Weise optimieren - aber das ist jetzt hier nicht das Thema]

    Einschränkungen:
    Diese Methode erlaubt es nicht, einzelne Apps auf die Sd-Karte zu verlagern, es geht nur für alle Apps oder für keine. Man kann nur wählen zwischen "nur *.apk files", "nur Dalvik-Cache", oder beides, oder nichts, aber diese Wahl betrifft dann halt alle (Nicht-System-)Apps.

    Methode C (kurz: Symbolic Links auf Dateien auf der SD-Karte):
    (Link2SD - kostenlose App aus dem Google Market)
    • ab Android 1.6 (oder sogar schon früher? - naja älteres Android hat hier eh niemand...)
      (momentan probleme mit Android 2.3, siehe Bemerkung ganz am ende des Postings)
    • "root" benötigt!
    • Zweite SD-Karten-Partition benötigt! (als zweite Partition nach der FAT32-Partition, aber auch als primary(!) Partition einrichten, und zwar als ext2/ext3/ext4 (ja nachdem, was dein Smartphone-System (ROM) unterstützt), ODER auch FAT32 (angeblich))
    • Auswahl auf "per App" Basis IST möglich (nur für Nicht-System-Apps)
    • Ob die zu verschiebende App ein "App2SD" gemäß "Methode A" unterstützt oder nicht, ist irrelevant.
    • Es kann (1), (2) und (3) verschoben werden (frei wählbar und kombinierbar pro App)
    Beschreibung:
    Das Prinzip ist das gleiche wie bei Methode B insofern, dass hier auch mit symbolic Links auf Orte auf der SD-Karte (2. Partition) gearbeitet wird. Der Unterschied ist der, dass nicht wie in Methode B ein Symbolic Link für ein ganzes Verzeichnis angelegt wird (für alle *.apk oder alle dalvik-cache-Dateien), sondern dass pro App und pro Kategorie (1)/(2)/(3) entschieden werden kann, ob eine "Umleitung" zur SD-Karte per symbolic link stattfinden soll. Die grafische Benutzeroberfläche wie auch das back-end-Prozessing stellt die App "Link2SD" bereit.Man kann auch hier jederzeit eine App (bzw.: Teil (1), (2) oder (3) einer App) zwischen internem und externem Speicher hin- und her schieben.
    Als Mountpunkt verwendet Link2SD übrigens "/data/sdext2/" für die zweite Partition der SD-Karte (laut Beschreibung des Autors selbst).

    Vorteil:
    Man kann viel flexibler das auf die SD-Karte verschieben, was am sinnvollsten ist.
    Eine sinnvolle Vorgehensweise ist, folgende Teile auf die SD-Karte zu verschieben:
    • (1) Alle *.apk Files (weil diese im operativen Betrieb nicht verwendet werden, also keine Geschwindigkeitseinbuße bei langsamer externen Speicherkarte)
    • (2) Dalvik-Cache: nur für die Apps, die eher selten verwendet werden und wo man ggf. geringe Geschwindigkeitseinbußen in Kauf nehmen kann, oder auch solche, die einen sehr großen dalvik-cache haben und wo es sich somit richtig lohnt.
    • (3) Library Dateien: gleiche Vorgehensweise wie für (2)
    Tipp: Über die Frage, welche Apps besonders große dalvik-cache oder library Files haben, kann man sich mit der gratis Market-App "diskusage" einen schnellen Überblick verschaffen!


    Kann man die Methoden miteinander kombinieren, und ist das sinnvoll?
    Möglich ist es teilweise schon, sinnvoll aber eigentlich nie, wie im Folgenden erörtert:

    Mischen von Methode A und B:
    Mit Methode B werden alle *.apk-Dateien auf die SD-Karte (ext-Partition) verlagert.
    Wenn wir jetzt noch Methode A ("2.2+ native") hinzunehmen, können wir uns einige Apps aussuchen, deren *.apk Files auf die erste Partition der SD-Karte nach "/sdcard/.android-secure/" verschoben werden. Das heißt, wir würden Apps (genauer: deren *.apk Files) zwischen SD-Karte Partition 2 (ext2/3/4) nach SD-Karte Partition 1 (FAT32) verschieben. Das bringt eigentlich genau gar nichts, außer in dem seltenen Fall, dass die eine Partition zu klein wird und wir es auf die andere verschieben müssen. Dann würden wir aber Methode A nicht dazu verwenden, den internen Telefonspeicher zu entlasten, sondern dazu, die zweite (offenbar zu klein bemessene) Partition der SD-Karte zu entlasten (auf kosten der FAT32-Datenpartition). In der Regel macht man aber die 2. Partition für die auszulagernden Dateien zwischen 500 und 1400 MB groß, und dann sollte dieser Platz immer dicke ausreichen, wenn man nicht gerade 100 speicherfressende Spiele installiert. Bem.: Nicht mehr als 1.4 GB, sonst kann's Probleme geben, wie mehrfach berichtet - aber soviel braucht man in der Regel eh nicht.

    Mischen von Methode A und C:
    Es gilt die gleiche Argumentation wie im vorigen Abschnitt.

    Mischen von Methode B und C:
    Einen Nutzen gibt es hier eigentlich überhautpt nicht, denn beide Methoden lagern die Dateien auf die selbe Partition der SD-Karte aus.
    Ich denke, es könnte aber zu Konflikten führen, denn beide Methoden verwenden diese Partition der SD-Karte auf unterschiedliche Weise. Je nachdem, unter welchen Verzeichnissen und Unterverzeichnissen die Dateien abgelegt werden, kann es im besten Fallen (bei sich nicht überscheidenden Namen) zu keinen Konflikten kommen, aber das ist unsicher.

    Ein weiterer Punkt ist das Mounting: Beide Methoden verwenden ein (eigenes) Script, das die 2. SD-card Partition ins Dateisystem einhängt (mountet). Je nachdem, wie intelligent diese Scripts geschrieben sind, merken sie, dass das Dateisystem schon eingehängt ist, oder die scripts "bocken". Also, es kann funktionieren, im besten Falle, aber kann auch hier zu Konflikten führen.
    Wie auch immer, ein möglicher Nutzen ist sowieso nicht zu sehen.

    ABER: Ein User hier hat hier berichtet, dass sein Link2SD (die benannte beta-Version) erfolgreich auf seinem Android 2.3 System läuft, auf einem System, wo App2SD (gemeint ist wohl die Methode B (?)) auch läuft. Eventuell hat hier die Methode B "für Link2SD" den Job übernommen, die SD-Partition zu mounten, und Link2SD hat darauf aufbauend dann eher "zufällig" gut funktioniert. Das würde ich aber nicht als die Regel ansehen, ich würde weiterhin sagen, das grundsätzlich Methode B und C nicht gemischt werden sollten weil sie sich nur gegenseitig stören könnten und es zu undefiniertem Verhalten kommen kann.

    D.h., bei einem fehlerfrei funktionierenden Link2SD (d.h. Android 1.6-2.2, und hoffentlich auch bald 2.3) sollte man ein mögliches A2SD-Feature (Methode B) seines Systems eher deaktivieren, um auf Nummer sicher zu gehen und Konflikte/undefiniertes Verhalten in bestimmten Situationen zu vermeiden.


    Zusammenfassung:
    Code:
                         |       Method A          |       Method B          |        Method C         |
                         |  (Native 2.2+ App2SD)   |   (A2SD, DT Apps2SD)    |        (Link2SD)        |
    ---------------------+-------------------------+-------------------------+-------------------------|
    Android Version      |          2.2+           |          1.6+           |  1.6+ (2.3:fix pending) |
    ---------------------+-------------------------+-------------------------+-------------------------|
    Root needed?         |          No             |          Yes            |          Yes            |
    ---------------------+-------------------------+-------------------------+-------------------------|
    2nd SD partition     |          No             |          Yes            |          Yes            |
    needed?              |                         | (ext2/3/4 acc. to ROM)  | (ext2/3/4, or FAT32     |
    ---------------------+-------------------------+-------------------------+-------------------------|
    All non-system apps  |          No             |          Yes            |          Yes            |
    can be moved?        | (only eligible apps)    |                         |                         |
    ---------------------+-------------------------+-------------------------+-------------------------|
    Indididual Apps      |          No             |          No             |          Yes            |
    can be selected?     | Move either all apps,   | Move either all apps,   |                         |
                         | or none.                | or none.                |                         |
    ---------------------+-------------------------+-------------------------+-------------------------|
    What can be moved?   |                         |                         |                         |
    *.apk files          |           Yes           |          Yes            |          Yes            |
    *.dex (dalvik-cache) |           No            | Yes (for some solutions)|          Yes            |
    *.so (libraries)     |           No            | Yes ("DT Apps2SD")      |          Yes            |
    other user data      |           No            | Yes ("DT Apps2SD")      |          No             |
    ---------------------+-------------------------+-------------------------+-------------------------|
    Handling             | Almost Fool-Proof       |  Sometimes comlicated   | Easy User interface,    |
                         |                         |                         | nearly fool-proof       |
    ---------------------+-------------------------+-------------------------+-------------------------|
    Impact if connected  |           Yes           |          No             |          No             |
    to WindowsPC via USB?|                         |                         |                         |
    
    Die letzte Zeile aus obiger Tabelle wurde noch gar nicht diskutiert. Was damit gemeint ist:
    Wenn man das Smartphone per USB an den Windows PC anschließt, wird die erste SD-Karten-Partition ungemountet. Das heißt, alle Apps, die nach Methode A ausgelagert sind, sind dann nicht mehr gemountet, wodurch z.B. App-Icons verschwinden können. Bei Methode B und C bleibt die zweite SD-Partition gemountet und der Betrieb wird nicht beeinträchtigt [könnte aber evtl. auch einen Impact haben, wenn es sich statt um einen Windows PC um einen Linux PC handelt...].


    FAZIT:
    So, das war's. Ich schaue noch mal auf die Liste der eingangs gestellten Fragen - ja, die sollten jetzt alle beantwortet sein.

    Methode C (Link2SD) ist eindeutig die beste Variante, weil am flexibelsten. Hiermit kann man am besten den internen Speicher optimal freischaufeln und gleichzeitig den Impact (durch Verlangsamung aufgrund langsamer SD-Karte) minimieren, indem man seine Auswahl richtig trifft. Das ist also besonders dann gut, wenn der Speicherplatz wirklich knapp ist.
    Außerdem ist Methode C (Link2SD) ähnlich einfach zu handhaben wie Methode A (native 2.2+), außer dem Erfordernis des zusätlichen Rootens (einmalige Sache, bei vielen Phones auch sehr einfach).

    Methode B (A2SD(+), DT App2SD, ...), d.h. feste Umleitung aller *.apk files, ist auch ok, wenn damit der interne Speicher ausreichend geleert wird. Sollte das aber mal nicht mehr ausreichen, weil z.B. die dalvik-cache-Dateien zu sehr anwachsen, dann muss man gleich zum "Hammer" greifen, der darin besteht, auch ALLE dalvik-cache-Dateien auf die SD-Karte auszulagern. Diese undifferenzierte Lösung kann zu Performance-Einbußen führen! Besser wäre es, zumindest die dalvik-cache Dateien, die häufig vom System (oder vom Benutzer) gebraucht werden (z.B. für den Homescreen Manager, SMS-App, ...) im internen Speicher zu belassen, zumal das ja gar nicht unbeding die größten Speicherfresser sein müssen.
    Außerdem ist diese Methode, vor allem wenn man die Variante "DarkTremor Apps2SD" (die leistungsfähigste) verwendet, eher etwas für Eingeweihte, die sich mit dem System auskennen und weniger etwas für End-User.

    Methode A (Android 2.2+ native) ist die schlechsteste Methode (auch für Benutzer von Android 2.2+), denn man kann NUR die *.apk-Dateien nach SD-Karte verlagern, und dann noch nicht einmal alle. Damit schafft man nur sehr wenig internen Speicher frei und wird sein grundsätzliches Speicher-Problem nur aufschieben, aber wohl meist nicht dauerhaft lösen.

    Ich erinnere nochmal daran, dass das verschieben von ALLEN *.apk-Dateien nach extern (wie nur mit Methode B oder C möglich) keine Perfomance-Einbußen im laufenden Betrieb mit sich bringt, weil Andoid im laufenden Betrieb auf diese Dateien gar nicht zugreift, sondern stattdessen die dalvik-cache-Dateien ausführt.


    Schlussbemerkung zu Link2SD (Methode C):
    Momentan (Anfang September 2011) scheint es Probleme mit Android 2.3 zu geben, hier funktioniert die Version im Market anscheinend nicht. Ich hab aber schon mit dem autor gemailt, und er ist dran, auch für 2.3 ein update zu bringen. Eine beta Version zum Testen hat er mir schon hier geschickt für willige beta-Tester (Rückmeldung an den Autor, was (nicht) geht und welches ROM ihr benutzt, ist natürlich sinnvoll)


    Links:


    Nachtrag vom user "[8]" bzgl Methode B mit dem Custom ROM "Cyanogenmod7" (vielen Dank im Namen aller):

    (Leider lässt sich mein "reserviertes" Nachfolge-Posting nicht mehr editieren)
     
    Andreas61, lecter1, Maxi1984 und eine weitere Person haben sich bedankt.
  2. michael_and, 12.09.2011 #2
    michael_and

    michael_and Threadstarter Erfahrener Benutzer

    Beiträge:
    165
    Erhaltene Danke:
    58
    Registriert seit:
    12.12.2010
    (reserviert für spätere Ergänzungen)
     
  3. L30nh4rt, 26.09.2011 #3
    L30nh4rt

    L30nh4rt Android-Lexikon

    Beiträge:
    1,015
    Erhaltene Danke:
    214
    Registriert seit:
    06.06.2011
    Phone:
    Nexus 5
    Hi Michael,

    erstmal danke für die Ausführungen!
    Eine Kurze frage: ergeben sich durch das verschieben von App´s die bereits nativ Android-App2SD unterstützen über zum Beispiel DT´s App2SD in die ext4-partition irgendwelche vor- oder nachteile? z.b. in Bezug auf Performance etc?
     
  4. michael_and, 26.09.2011 #4
    michael_and

    michael_and Threadstarter Erfahrener Benutzer

    Beiträge:
    165
    Erhaltene Danke:
    58
    Registriert seit:
    12.12.2010
    eigentlich nicht, es gilt nur das unter "Mischen von Methode A und B" geschriebene.
     
  5. Platinumviper, 27.09.2011 #5
    Platinumviper

    Platinumviper Neuer Benutzer

    Beiträge:
    10
    Erhaltene Danke:
    1
    Registriert seit:
    23.03.2011
    Zunächst mal Danke für die Ausführungen, sehr gut geschrieben. Hab dann auch gleich mal ein bisschen getestet (AmberHome 2.0 mit DT a2sd).
    Wenn man in den USB modus geht, wird nur die erste Partition unmounted, die zweite bleibt gemountet, wird aber vom PC auch gemounted (falls ein Treiber vorhanden ist). Da das Linux auf dem Handy nicht weiß, das da noch ein anderes Linux/MacOS/Windows rumfummeln kann, sollte man vom PC aus auch nicht darauf rumfummeln, das hätte nur verstümmelte oder zerstörte Dateien zur Folge. Datentransfers sollten nur über die DOS Partition erfolgen.
    Ob man für die 2. Partition ext3 oder ext4 verwendet ist egal, der Geschwindigkeitsunterschied ist bei SD-Karten wahrscheinlich nicht einmal messbar und schon gar nicht spürbar. FAT32/VFAT ist erheblich langsamer und kann kein journaling. Ext2 kann ebenfalls kein journaling, ist aber das schnellste FS. Ich würde ext3 empfehlen.
    Ob der Kernel ext4 überhaupt unterstützt lässt sich leicht überprüfen:
    Im Terminal oder "adb shell": cat /proc/filesystems
    Falls DT a2sd installiert ist im Terminal oder "adb shell": a2sd check
    da gibt's dann auch gleich ein paar Hinweise, alles mit [!] oder [X] Markierung sollte geändert werden, wie das geht steht in der Zeile direkt darunter.

    Ich frage mich gerade warum es keine /etc/fstab gibt und ob die erste Partition überhaupt so eine veraltete DOS Struktur haben muss, mit einem ext3 FS würde vieles deutlich schneller gehen, muss ich in den nächsten Tagen mal testen.
     
  6. regn, 02.10.2011 #6
    regn

    regn Erfahrener Benutzer

    Beiträge:
    159
    Erhaltene Danke:
    3
    Registriert seit:
    19.05.2011
    Phone:
    Huawei Ascend G330
    kann nur mutmaßen: fstab ist sinnvoll, wenn admins öfter mounten und umounten, da device und Parameter definiert sind. Da das aber bei Android nicht passiert, kann man darauf verzichten. Aber wo stehen dann die mount-Befehle ?

    Und: Wenn die 2.Partition ext2/3/4 ist, kann der dumme PC die doch gar nicht lesen!

    Und: Ubernimmt link2sd auch das neupartitionieren der SD-karte (mit Datenerhalt)?
    Das Verschieben selbst ist ja trivial - hier für die apk:

    Code:
    # SD2 evtl. anpassen - vorher filesystem anlegen
    SD2=/dev/block/vold/179:2
    mount $SD2 /data/sdext2
    cd /data/app
    for i in *.apk
    do mv -i $i /data/sdext2 && ln -s /data/sdext2/$i .
    done
    was ich gar nicht verstehe: bei mir zeigt disk usage zwar die Größe der /data -Partition an, es listet aber alle apps, auch die vorinstallierten, auf.
     
  7. Platinumviper, 08.10.2011 #7
    Platinumviper

    Platinumviper Neuer Benutzer

    Beiträge:
    10
    Erhaltene Danke:
    1
    Registriert seit:
    23.03.2011
    Doch, auch PCs können mehrere Partitionen mounten, Platten mit nur einer Partition sind eher die Ausnahme.
    Wenn die erste Partition eine normale ext3 ist, wird die nicht gemountet. VFAT für die erste Partition ist also irgendwo fest eingestellt, dämliche Idee.
     
  8. regn, 08.10.2011 #8
    regn

    regn Erfahrener Benutzer

    Beiträge:
    159
    Erhaltene Danke:
    3
    Registriert seit:
    19.05.2011
    Phone:
    Huawei Ascend G330
    Führt zwar jetzt etwas vom Thema weg, aber ich meinte mit lesen nicht mounten, sondern: Ein Windows hat keine Kenntnis, wie ein ext2 Filesystem aufgebaut ist, und kann dessen files nicht lesen.

    aber zurück zum link2SD: Speicherkarten haben ja eine Partition, die die ganze Karte ausfüllt. Um eine 2. anzulegen, müssen die Daten der ersten Partition erstmal gesichert und dann zurückkopiert werden. Gibt es da irgendeine Unterstützung von link2SD?
    vG
     
  9. michael_and, 08.10.2011 #9
    michael_and

    michael_and Threadstarter Erfahrener Benutzer

    Beiträge:
    165
    Erhaltene Danke:
    58
    Registriert seit:
    12.12.2010
    --> Auch etwas off-topic, aber ich lese diese Behauptung immer wieder. Stimmt gar nicht, Abhilfe ist sehr einfach und funktioniert hervorragend (read & write) (Link hier (Ext2IFS)):
    [​IMG]

    Oder diese Alternative (Ext2Fsd) (hab ich nicht probiert, da ersteres (Ext2IFS) bei mir schon zur vollsten Zufriedenheit funktioniert (WInXP SP3))
     
  10. regn, 08.10.2011 #10
    regn

    regn Erfahrener Benutzer

    Beiträge:
    159
    Erhaltene Danke:
    3
    Registriert seit:
    19.05.2011
    Phone:
    Huawei Ascend G330
    Es gibt eine Abhilfe? Aber dann ist das doch klar, daß Windows ext2 nicht lesen kann, sonst müßte man ja keine Abhilfe schaffen.

    Ich habe ja nicht behauptet, daß es keine Erweiterungen für Windows gibt, die das können, Windows selbst kann es aber nicht. MS hat sich noch nie um andere geschert!
     
  11. michael_and, 08.10.2011 #11
    michael_and

    michael_and Threadstarter Erfahrener Benutzer

    Beiträge:
    165
    Erhaltene Danke:
    58
    Registriert seit:
    12.12.2010
    ja, stimmt, das war etwas blöd von mir formuliert. Ich wollte nur andere Benutzer auf diese Möglichkeit hinweisen.

    Für mich ist das äußerst praktisch, ich arbeite auf Linux, hab aber noch eine Notfall-WinXP-Partition (dual Boot), denn z.B. für SW-Updates auf Smartphones (flashen) braucht man ja leider noch Windows, auch wenn es Linux (Android)-Smartphones sind...

    Und dann ist es praktisch, wenn ich bei Bedarf von Windows aus auf meine komplette ext3-Datenpartition zugreifen kann.
     
  12. Platinumviper, 08.10.2011 #12
    Platinumviper

    Platinumviper Neuer Benutzer

    Beiträge:
    10
    Erhaltene Danke:
    1
    Registriert seit:
    23.03.2011
    So gesehen kann Windows auch mit dem meisten Druckern, TV-Karten usw nichts anfangen, einen Treiber muss man fast immer installieren.

    Zurück zum Thema:
    link2SD kann das nicht. Du kannst z.B. http://partedmagic.com/doku.php benutzen um die Partitionen ohne Datenverlust zu verkleinern oder zu vergrößern. Installation am einfachsten per UNetbootin - Homepage and Downloads.
     
  13. email.filtering, 10.10.2011 #13
    email.filtering

    email.filtering Gast

    Nicht, dass ich wüsste, doch bevor ich die Partition "fliegend" verkleinere, und dazu auch noch eine Software (wie den Partiton Wizard von Minitool) installieren muss, habe ich das Zeug schon längst manuell hin- und hergeschubst und dabei auch gleich mal ein Backup angelegt bzw. eine Großreinigung gemacht.
     
  14. regn, 12.10.2011 #14
    regn

    regn Erfahrener Benutzer

    Beiträge:
    159
    Erhaltene Danke:
    3
    Registriert seit:
    19.05.2011
    Phone:
    Huawei Ascend G330
    Welchen Typ verwendet man denn am besten für die 2. Partition? Miachael_and schreibt ja, ext2/3/4 oder fat, aber würde denn android ein fsck laufen lassen, wenn der Akku zu Ende gegangen war, bevor das Linux runtergefahren hat?
    Und was ist mit dem yaffs? schont das evtl. die SD-Card durch weniger Schreiboperationen (ich denke da an access-time updates der inode in ext2) ? In der Doku steht da was von YAFFS has lower memory footprints

    vG
     
  15. email.filtering, 13.10.2011 #15
    email.filtering

    email.filtering Gast

    Das hängt wohl alles auch sehr stark davon ab, welche Dateisysteme die von Dir installierte Betriebssystemversion unterstützt. Mit EXT2 bist Du definitiv auf der sicheren Seite. Und da Android ohnedies kein Journaling nutzt bzw. unterstützt, ist alles andere sinnloser Ballast.

    BTW, die meisten Speicherkarten sterben den Spannungsspitzentod, und keinesfalls deswegen, weil ein OS wie Android zu viele Schreibvorgänge darauf durchführte.
     
  16. Jarny, 13.10.2011 #16
    Jarny

    Jarny Android-Experte

    Beiträge:
    523
    Erhaltene Danke:
    38
    Registriert seit:
    01.06.2009
    Danke erstmal für den super Beitrag auf Seite 1. Gute Erklärungen, jetzt versteh ich das App2SD-Thema bisschen besser.:thumbsup:
    Ich muss mir demnächst für mein ungerootetes Desire was einfallen lassen. Der Speicher platzt aus allen Nähten des ansonsten für meine Zwecke immernoch ausreichenden Handys. Hab schon alle Apps mit dem normalen App2SD von Frodo auf meine SD-Karte geschoben.

    Was ich bei den Ausführungen nicht ganz verstehe: Wenn die Erklärung für Methode A (normales App2SD) stimmt und lediglich das APK verschoben wird, warum muss diese Methode "vom Programmierer vorgesehen sein" ? Das muss doch völlig egal für die Applikation sein. Die App macht doch nichts mir ihrem eigenen APK, bzw. selbst wenn, müsste doch durch den symbolischen Link auch damit alles funktionieren.
    Hat da jemand ne plausible Erklärung? Logisch wäre für mich, wenn nur das Betriebssystem, bzw. Dalvik (nur beim Anlegen des Caches) auf das APK zugreift.

    Gruß
    Jarny
     
  17. regn, 14.10.2011 #17
    regn

    regn Erfahrener Benutzer

    Beiträge:
    159
    Erhaltene Danke:
    3
    Registriert seit:
    19.05.2011
    Phone:
    Huawei Ascend G330
    @Jarny:
    Gute Frage, hoffentlich findet sich hier ein Insider. Eigentlich wird das .apk file ja sowieso nach dem 1. Lauf nicht mehr gebraucht, denn es wird ja nur der Bytecode im dalvik-cache interpretiert.
    Tatsache ist aber, daß das Icon zum Start der App sofort verschwindet, sogar auch dann, wenn man (in Android 2.1.1)

    Code:
    mv /data/app/XXX.apk /data/sdext2
    ln -s /data/sdext2/XXX.apk  /data/app/XXX.apk
    eingibt.
    Ich habe das deswegen mal probiert, weil ich mit link2SD das Ärgernis habe, daß jede gelinkte APP im screen ans Ende rutscht und damit meine Sortierung der Apps zerstört wird.

    grüße
     
  18. Jangrie, 15.10.2011 #18
    Jangrie

    Jangrie Android-Guru

    Beiträge:
    2,710
    Erhaltene Danke:
    312
    Registriert seit:
    28.12.2010
    ich haette mal kurz ne Frage. Hab es genau so wie du gemacht, nachdem ich Gingerreal 1.4 installiert hab, DT Script bei boot deaktiviert und A2SDGUI steht Apps befinden sich auf dem internen Speicher. hab auch manuell erstmal alles auf intern geknallt. So dann Link2Sd installiert und probehalber die 9 Apps die gingen verlinkt..allerdings ging dann keine einzige App mehr und ich musste sie mit Link2SD neuinstallieren..mach ich was falsch?!
     
  19. Schlüti83, 19.10.2011 #19
    Schlüti83

    Schlüti83 Neuer Benutzer

    Beiträge:
    1
    Erhaltene Danke:
    0
    Registriert seit:
    19.10.2011
    Hallo liebe Androidgemeinde,

    ich bin neu hier und hoffe nicht gleich negative aufzufallen, weil ich nicht ordentlich suche :winki: aber mich würde interessieren ob schon jemand versucht hat "Maps", "WhatsApp", "Market" und/oder "Facebook" mit Link2SD auf die SD-Karte zu verschieben?? Hat jemand Erfahrungen gesammelt?
    Ich selbst habe das Galaxy 551 und frisch gerootet^^

    Freu mich auf Antworten:biggrin:
     
  20. chris67, 21.10.2011 #20
    chris67

    chris67 Android-Lexikon

    Beiträge:
    1,554
    Erhaltene Danke:
    295
    Registriert seit:
    27.10.2010
    link2sd läuft auf meinem ZTE Skate mit Android 2.3.4 völlig problemlos.
    Der Hinweis, dass link2sd nicht mit Android 2.3.x kann, ist also wohl mittlerweile überholt.
     
Status des Themas:
Es sind keine weiteren Antworten möglich.

Diese Seite empfehlen