Android-Sideloading: Sicherheit contra Nutzerfreiheit

Google hat es deutlich schwerer gemacht, Apps außerhalb des Play Stores zu installieren. Der neue Ablauf verlangt für Sideloading-Apps, die nicht von Google Play Protect verifiziert wurden, eine 24-stündige Wartezeit. In dieser Zeit wird die APK zur Prüfung auf Googles Server hochgeladen. Installierst du eine App aus einer Drittquelle, musst du also einen ganzen Tag warten, bevor du sie nutzen kannst. Die Sicherheitsbegründung ist klar: Mit Malware verseuchte APKs sind ein echtes Problem, besonders in Regionen, in denen Sideloading verbreitet ist. Die Reaktion von Entwicklern und Power-Usern fällt... weniger freundlich aus.

Diese jüngste Änderung steht im Zentrum eines Spannungsfelds, das Android seit seinem Anfang prägt: Wie gibt man Nutzern die Freiheit, zu installieren, was sie wollen, und schützt gleichzeitig diejenigen, die nicht wissen, was sie tun? Android arbeitet seit 18 Jahren an dieser Frage, und die Antwort ändert sich immer wieder.

Eine kurze Geschichte der App-Installation unter Android

Früh war Android im Grunde der Wilde Westen. Jede App ließ sich mit einem Tipp aus jeder beliebigen Quelle installieren. Der Schalter „Unbekannte Quellen“ in den Einstellungen war ein globaler Schalter: Aktiviert man ihn, durfte jede App auf dem Gerät APKs installieren. Das war simpel, stärkte die Nutzer und war ein absoluter Sicherheitsalptraum.

Android 8 (Oreo, 2017) führte Berechtigungen pro Quelle ein. Statt eines globalen Schalters musste jede App einzeln die Berechtigung „Unbekannte Apps installieren“ anfordern. Dein Browser durfte APKs installieren, während dein E-Mail-Client das nicht konnte. Das war eine echte Verbesserung, denn so blieb der Schaden durch eine kompromittierte App begrenzt.

Android 13 brachte eingeschränkte Einstellungen. Sideloaded Apps konnten bestimmte sensible APIs (Bedienungshilfen, Benachrichtigungs-Listener) nicht mehr ohne zusätzliche Bestätigungsdialoge nutzen. Die Logik: Apps von außerhalb des Play Stores wurden nicht geprüft, also sollten sie nicht ohne Weiteres an die mächtigsten Berechtigungen kommen.

Jetzt kommt mit der 24-stündigen Prüfung eine weitere Reibungsebene hinzu. Jede Iteration macht Sideloading schwieriger, und jede wird mit echten Sicherheitsdaten begründet. Die Frage ist, ob die kumulierte Reibung die Grenze überschritten hat von „Nutzer schützen“ zu „Nutzer in den Play Store zwingen“.

Warum Sideloading ein echtes Sicherheitsproblem ist

Bevor wir Googles Bedenken abtun: Sideloading-Malware ist ein echtes Problem in großem Maßstab. Googles eigene Daten zeigen, dass Apps, die von außerhalb des Play Stores installiert werden, 50-mal häufiger Malware enthalten als Play-Store-Apps. In Märkten wie Südostasien, wo Drittanbieter-Stores beliebt sind, liegen die Infektionsraten deutlich höher als in Märkten, in denen der Play Store dominiert.

Der Angriffsvektor ist erschreckend effektiv. Ein Nutzer bekommt eine Nachricht – WhatsApp, SMS, E-Mail – mit einem Link zu einem „Bank-Sicherheitsupdate“, einem „Handyreiniger“ oder einer „kostenlosen Premium-App“. Er lädt die APK herunter, ignoriert die Sicherheitswarnungen (weil man sich an das Wegklicken gewöhnt hat) und installiert sie. Die Malware bekommt Zugriff auf die Bedienungshilfen (wieder, weil der Nutzer dazu gebracht wurde, sie zu erlauben), stiehlt Bankdaten, fängt SMS-Bestätigungscodes ab oder verschlüsselt das Gerät für eine Lösegeldforderung.

Das sind keine ausgeklügelten Angriffe. Sie funktionieren, weil Social Engineering wirkt und weil die meisten Nutzer das Risiko nicht verstehen, beliebigen Code zu installieren. Googles Position ist, dass Reibung – Sideloading langsamer und schwieriger zu machen – die wirksamste Verteidigung ist, weil sie dem Nutzer Zeit zum Nachdenken gibt und Google Gelegenheit, die APK zu prüfen.

Warum Entwickler frustriert sind

Der Widerstand der Entwickler dreht sich nicht um Malware. Es geht um Kontrolle, Vertrieb und die wachsende Hürde, Apps außerhalb von Googles Ökosystem zu den Nutzern zu bringen.

Testen und Entwicklung. Entwickler sideloaden während der Entwicklung ständig. Eine 24-stündige Wartezeit für jeden Testbuild ist absurd. Google umgeht das, indem Apps, die über ADB (Android Debug Bridge) installiert werden, ausgenommen sind. Aber nicht jeder Testablauf nutzt ADB – QA-Teams, Beta-Tester und Kundendemos installieren APKs oft direkt.
Unternehmensverteilung. Firmen, die interne Apps außerhalb des Play Stores verteilen (verwaltet über MDM-Lösungen), stoßen auf zusätzliche Hürden. Große Unternehmen mit MDM können einige Einschränkungen umgehen, kleinere Organisationen ohne MDM-Infrastruktur dagegen nicht.
Alternative App-Stores. F-Droid, Amazon Appstore, Samsung Galaxy Store – aus Googles Sicht sind all diese legitimen Vertriebswege Sideloading. Jede zusätzliche Einschränkung verschlechtert ihre Nutzererfahrung im Vergleich zum Play Store, und genau das werfen Kritiker Google vor.
Regulatorische Vorgaben. Der Digital Markets Act der EU verpflichtet Gatekeeper (darunter Google), Sideloading ohne unangemessene Hürden zu erlauben. Sideloading wesentlich zu verschlechtern und es technisch nur noch gerade so möglich zu lassen, ist genau die Art von Compliance-Theater, die der DMA verhindern sollte.

Die tieferen Probleme des Berechtigungsmodells

Sideloading-Beschränkungen sind ein Pflaster auf einem tieferliegenden Problem: Androids Berechtigungsmodell verlangt von Nutzern Sicherheitsentscheidungen, für die sie nicht gerüstet sind. „Dieser App Zugriff auf deine Kontakte erlauben?“ „Dieser App erlauben, deine SMS zu lesen?“ „Dieser App die Bedienungshilfen erlauben?“ Die meisten Nutzer verstehen die Folgen nicht und akzeptieren entweder alles oder lehnen alles ab.

Das Kernproblem: Berechtigungen werden als binäre Entscheidungen über Fähigkeiten formuliert, obwohl Nutzer in Zwecken denken. Ein Nutzer will nicht entscheiden, ob eine App SMS lesen darf. Er will entscheiden, ob die App seine Telefonnummer verifizieren darf (vernünftig) oder die Zwei-Faktor-Codes seiner Bank abfangen darf (nicht vernünftig). Beides erfordert dieselbe Berechtigung.

<!-- AndroidManifest.xml -->
<!-- Both of these use the same permission: -->
<uses-permission android:name="android.permission.READ_SMS" />
<!-- Use case 1: Auto-fill SMS verification code during signup -->
<!-- Perfectly legitimate, saves the user time -->
<!-- Use case 2: Intercept banking 2FA codes and forward to attacker -->
<!-- Malware, obviously -->
<!-- The permission system can't distinguish between these.
The user is asked to make a security decision that requires
understanding the app's implementation, which they can't see. -->

iOS hat das „gelöst“, indem Sideloading komplett verboten wurde (bis regulatorischer Druck begrenzte Alternativen erzwang). Das ist ein legitimer Ansatz – die Entscheidung wird den Nutzern vollständig abgenommen –, bringt aber eigene Kosten mit sich: Abhängigkeit von Entwicklerplattformen, Mietpreise im App Store und die Unmöglichkeit, Software auszuführen, die Apple nicht freigegeben hat.

Wie ein besseres System aussehen könnte

Weder Apples „kein Sideloading“-Ansatz noch Androids „Sideloading mit wachsender Reibung“ ist ideal. Ein besseres System müsste mehrere Dinge gleichzeitig angehen.

Risikoproportionale Hürden. Eine App, die keine gefährlichen Berechtigungen anfordert und von einem bekannten Entwickler signiert wurde, sollte sofort installierbar sein. Eine App, die Bedienungshilfen, SMS-Zugriff und Geräteadministratorrechte verlangt, sollte stärker geprüft werden. Das aktuelle System behandelt einen harmlosen Open-Source-Taschenrechner und eine berechtigungshungrige App, die alles will, gleich.
Zweckgebundene Berechtigungen. Statt „SMS lesen“ pauschal zu gewähren, sollte es „SMS lesen zum automatischen Ausfüllen von Bestätigungscodes“ heißen – eine eingeschränkte Berechtigung, die nur in bestimmten API-Kontexten genutzt werden kann. Android ist mit dem SMS Retriever API in diese Richtung gegangen, doch die meisten Berechtigungen bleiben breit gefasst.
Transparente Prüfung ohne Wartezeit. Hochladen und Prüfen ist vernünftig. Eine 24-stündige Wartezeit ist es nicht, zumal die meisten Prüfungen in Minuten abgeschlossen sind. Man sollte Nutzern das Prüfergebnis zeigen, die Installation bei sauberem Ergebnis sofort erlauben und bei Auffälligkeiten warnen.
Gleichbehandlung von Play Store und Drittanbieter-Stores. Wenn der Play Store Apps sofort installieren kann, sollten alternative Stores das auch können – vorausgesetzt, sie setzen gleichwertige Sicherheitsprüfungen um. Das Sicherheitsargument trägt nur, wenn es bei den Einschränkungen um Sicherheit geht und nicht um Wettbewerbsvorteile.

Was Entwickler jetzt tun sollten

Unabhängig davon, was du von Googles Vorgehen hältst: Die praktische Realität ist, dass die Hürden für Sideloading steigen und kaum sinken werden. Wenn du Apps außerhalb des Play Stores verteilst, solltest du das einplanen.

Nutze das Play App Signing-Programm. Apps, die über Googles Programm signiert werden, könnten bei der Sideloading-Prüfung auf weniger Hürden stoßen, weil Google die Signatur mit bekannten Schlüsseln abgleichen kann.
Für die Entwicklung ADB verwenden. Mit ADB installierte Apps umgehen die 24-stündige Wartezeit. Stelle sicher, dass deine CI/CD-Pipelines und Testabläufe ADB statt direkter APK-Installation nutzen.
Progressive Web Apps in Betracht ziehen. Für Apps, die keine tiefe Plattformintegration brauchen, umgehen PWAs den App Store und die Sideloading-Frage komplett. Sie werden direkt im Browser installiert, aktualisieren sich automatisch und benötigen zur Installation keine besonderen Berechtigungen.
Wenn du einen alternativen Store betreibst, implementiere robuste Prüfungen. Stores, die starke Sicherheitspraktiken nachweisen, bekommen womöglich irgendwann Ausnahmen oder geringere Hürden – die regulatorische Lage geht in diese Richtung.
Verzögerungen klar kommunizieren. Wenn deine Verteilung auf Sideloading basiert, warne Nutzer von Anfang an vor der 24-stündigen Wartezeit. Eine erwartete Verzögerung frustriert weniger als eine überraschende.

Androids Offenheit war schon immer ein Spektrum und kein Absolutum. Jede Version hat dieses Spektrum ein Stück in Richtung mehr Kontrolle verschoben, begründet mit echten Sicherheitsbedenken und kritisiert dafür, dass die Schritte zufällig gut zu geschäftlichen Interessen passen. Die 24-stündige Sideloading-Verzögerung ist der jüngste Punkt auf dieser Entwicklung – wahrscheinlich nicht der letzte. Ob man sie als vernünftigen Schutz oder als künstlich erzeugte Reibung sieht, hängt stark davon ab, wo man die Balance zwischen Sicherheit und Freiheit ansiedelt. Die technische Realität ist aber eindeutig: Die Zeiten des reibungslosen Sideloadings auf Android sind vorbei, und Entwickler müssen ihre Vertriebsstrategien entsprechend anpassen.