Wo die Gigabytes wirklich liegen
Der Plattenappetit von Android verteilt sich auf vier Territorien, und die Pfade zu kennen lohnt sich, weil die IDE nur eines davon verwaltet. Das SDK liegt unter %LOCALAPPDATA%\Android\Sdk, die virtuellen Geräte des Emulators unter %USERPROFILE%\.android\avd und Gradle unter %USERPROFILE%\.gradle — jedes mit eigenen Aufräumregeln und einer eigenen Art zurückzubeißen, wenn Sie blind löschen.
Schlimmste Sünder sind die SDK-System-Images: jede Kombination aus Android-Version und CPU-Architektur, die Sie je akzeptiert haben, wiegt ein bis zwei GB und bleibt für immer. Danach kommen die AVDs des Emulators — ein einziges virtuelles Gerät mit Snapshots und qcow2-Platte kann über 10 GB erreichen. Gradle-Caches sammeln jede Abhängigkeit, die irgendein Projekt je aufgelöst hat, und jeder build/-Ordner pro Projekt stapelt Zwischendateien, an die sich niemand mehr erinnert.
- %LOCALAPPDATA%\Android\Sdk\system-images — jede je geladene Kombination aus Android-Version und ABI, je 1–2 GB
- %USERPROFILE%\.android\avd — Emulator-Images; ein AVD mit Snapshots und qcow2-Platten kommt leicht über 10 GB
- %USERPROFILE%\.gradle\caches — jede Abhängigkeit aller Projekte, gefahrlos neu aufbaubar und oft 20 GB+
- %USERPROFILE%\.gradle\wrapper\dists — jede Gradle-Version, die irgendein Projekt je angefordert hat, je rund 150 MB
- build/ und .gradle/ in jedem Projekt — Zwischendateien, die Sie jederzeit löschen können
- %LOCALAPPDATA%\Google\AndroidStudio* — Indizes, Logs und Caches der IDE selbst, nach jedem Update neu geboren
Was Sie löschen dürfen — und was nie
Löschen Sie über die Manager-Oberflächen, wo es welche gibt. Im SDK Manager deinstallieren Sie System-Images und alte build-tools für Android-Versionen unterhalb Ihrer minSdk — er aktualisiert die Metadaten und hält das SDK konsistent. Im Device Manager löschen Sie nicht mehr genutzte AVDs, und bei einem zickigen Gerät greifen Sie zu Wipe Data im Dropdown: Zurücksetzen statt ein 10-GB-Fossil zu hüten.
Gradle-Caches dürfen Sie komplett leeren — der nächste Build lädt nach, was er braucht, und Sie zahlen mit Zeit und Bandbreite, nicht mit kaputten Projekten. Dasselbe gilt für die build-Ordner der Projekte, weshalb ein zu archivierendes Projekt vorher eine build/-Razzia verdient. Nie anfassen: %USERPROFILE%\.android als Ganzes — dort liegen Ihr Debug-Keystore und die adb-Schlüssel, und ein verlorener Debug-Keystore bedeutet, jeden Debug-Build auf jedem Ihrer Geräte neu zu installieren.
So bleiben Sie schlank
Bauen Sie drei Gewohnheiten ein. Steigt das minSdk, investieren Sie fünf Minuten in den SDK Manager und werfen Sie die Versionen darunter raus. Halten Sie pro Formfaktor ein aktuelles Emulator-Image statt fünf, und greifen Sie zu Wipe Data statt Snapshots, wenn Sie nur ein frisches Gerät brauchen. Steht C: unter Druck, verlegen Sie das SDK über Settings → Languages & Frameworks → Android SDK und zeigen Sie GRADLE_USER_HOME auf ein anderes Laufwerk.
Die wiederkehrenden Reste — Gradle-Caches, IDE-Caches und Logs, Projekts-Build-Ordner — verdienen zweimal im Jahr eine Razzia. Ein Werkzeug, das Entwicklerordner kennt, etwa die Dev-Caches-Kategorie in Kleaner PRO, räumt Gradle- und IDE-Reste in einem Rutsch weg und lässt Keystores in Ruhe; egal wie Sie es machen: Studio vorher schließen, damit mitten im Löschen nichts gesperrt ist.
Fragen und Antworten
Kann ich den Gradle-Cache-Ordner löschen?
Ja — Studio vorher schließen, dann %USERPROFILE%\.gradle\caches löschen. Der nächste Build lädt alles Nötige neu; das kostet Zeit, nicht kaputte Projekte.
Wie gebe ich Speicher bei Android-Emulatoren frei?
In Android Studio den Device Manager öffnen, ungenutzte AVDs löschen und bei den behaltenen Wipe Data nutzen — ein vergessenes Image kann 10 GB binden.
Vor dem Kauf genau wissen, was enthalten ist.
Der einmalige 30-Minuten-Test umfasst Basisfunktionen. PRO-markierte Werkzeuge bleiben bis zur Aktivierung einer kostenpflichtigen Lizenz gesperrt.
Weiterlesen
Schreiben Sie uns: [email protected]