Wer einen kleinen Schritt in Richtung digitaler Souveränität gehen möchte, muss nicht gleich sein komplettes Smartphone umbauen.
Man muss auch nicht von heute auf morgen sämtliche Google-Dienste entfernen.
Ein ziemlich einfacher Anfang kann darin bestehen, sich einmal anzusehen, woher die eigenen Apps eigentlich kommen.
Auf den meisten Android-Smartphones lautet die Antwort darauf:
Google Play Store.
Aber Android bietet – zumindest bislang – noch eine Besonderheit, die es grundlegend von stärker abgeschotteten Plattformen unterscheidet:
Apps können auch aus anderen Quellen installiert werden.
Eine dieser Quellen ist F-Droid.
Und gerade jetzt könnte dieser unscheinbare alternative App-Store interessanter werden als je zuvor.
Denn Google verändert die Regeln.
F-Droid – ein App-Store ohne Google-Konto
F-Droid ist ein freies und quelloffenes Ökosystem zur Verteilung von Android-Anwendungen.
Im offiziellen F-Droid-Repository findet man ausschließlich freie beziehungsweise Open-Source-Software. Der F-Droid-Client ermöglicht es, diese Anwendungen zu suchen, zu installieren und anschließend auch ihre Aktualisierungen zu verwalten.
Dabei unterscheidet sich F-Droid an einigen Stellen grundlegend von dem, was wir von klassischen App-Stores gewohnt sind.
Zum Beispiel braucht man:
kein Benutzerkonto.
Keine Anmeldung.
Keine Telefonnummer.
Keine E-Mail-Adresse.
Kein Google-Konto.
F-Droid bezeichnet das ausdrücklich als bewusste Designentscheidung. Für die Bereitstellung von Apps an Nutzer werden keine Benutzerkonten verwendet und F-Droid erklärt, dass der Client nicht dafür entwickelt wurde, einzelne Nutzer zu identifizieren oder ihre Installationen zu verfolgen.
Eigentlich erstaunlich, dass etwas so Einfaches mittlerweile erwähnenswert ist.
Open Source ist hier nicht nur ein Werbespruch
F-Droid möchte nicht einfach irgendein alternativer Download-Katalog sein.
Bei Anwendungen im offiziellen Repository spielt der öffentlich zugängliche Quellcode eine zentrale Rolle.
F-Droid beschreibt seinen Prozess so: Der Quellcode einer Anwendung wird geprüft, anschließend kann die Anwendung über die Infrastruktur von F-Droid gebaut und für die Verteilung bereitgestellt werden. Bei reproduzierbaren Builds kann darüber hinaus überprüft werden, ob die veröffentlichte Anwendung tatsächlich dem angegebenen Quellcode entspricht.
Das bedeutet natürlich nicht automatisch:
Open Source = vollkommen sicher.
Auch offene Software kann Fehler oder Sicherheitslücken enthalten.
Der entscheidende Unterschied ist ein anderer:
Der Code kann prinzipiell untersucht werden.
Und F-Droid versucht zusätzlich sichtbar zu machen, wenn eine Anwendung Eigenschaften besitzt, die für den Nutzer möglicherweise unerwünscht sind.
Dafür gibt es die sogenannten Anti-Features.
Dazu können beispielsweise Werbung, Tracking, proprietäre Abhängigkeiten oder andere Eigenschaften gehören. Anwendungen, die von F-Droid mit dem Anti-Feature „Tracking“ gekennzeichnet wurden, werden im F-Droid-Client standardmäßig sogar ausgeblendet.
Das ist ein interessantes Gegenmodell.
Nicht:
„Vertrau uns einfach.“
Sondern eher:
„Hier sind die Informationen – entscheide selbst.“
Google Play muss deshalb nicht sofort verschwinden
Auch hier möchte ich nicht den Eindruck vermitteln, digitale Souveränität funktioniere nur nach dem Prinzip:
Alles oder nichts.
Man kann F-Droid problemlos zusätzlich zum Google Play Store verwenden.
Vielleicht installiert man zunächst nur eine Anwendung darüber.
Später eine zweite.
Vielleicht entdeckt man eine Open-Source-App, die eine bisher verwendete proprietäre Anwendung ersetzt.
Oder man stellt irgendwann fest:
Google Play wird eigentlich kaum noch benötigt.
Das muss jeder selbst entscheiden.
Digitale Souveränität ist kein Wettbewerb darum, wer sein Smartphone am schnellsten von allen kommerziellen Diensten befreit.
Es ist ein Prozess.
Aber genau dieser Prozess bekommt gerade eine interessante politische und technische Dimension.
Denn Google verändert die Art und Weise, wie Apps außerhalb des Play Stores installiert werden können.
Google möchte wissen, wer Android-Software verteilt
Am 25. August 2025 kündigte Google eine neue Android Developer Verification an.
Bis dahin konnte ein Entwickler beispielsweise eine APK auf seiner eigenen Webseite veröffentlichen.
Oder den Quellcode eines kleinen Projektes bereitstellen.
Oder seine Anwendung über einen alternativen App-Store verteilen.
Der Nutzer konnte entscheiden, ob er diese Anwendung installiert.
Googles neue Idee verändert dieses Verhältnis.
Bei der Developer Verification wird die reale Identität eines Entwicklers mit seinen Anwendungen beziehungsweise deren Paketnamen verknüpft.
Google begründet das mit Sicherheit.
Schädliche Entwickler sollen sich nicht einfach hinter wechselnden anonymen Identitäten verstecken und nach einer Sperrung erneut Schadsoftware verteilen können.
Das ist zunächst durchaus nachvollziehbar.
Doch Googles ursprüngliche Ankündigung ging wesentlich weiter als eine zusätzliche Sicherheitsprüfung im Play Store.
Sie betraf ausdrücklich auch Software, die außerhalb von Google Play verteilt wird.
Im ursprünglichen Zeitplan hieß es für die ersten betroffenen Länder sinngemäß:
Auf zertifizierten Android-Geräten müsse jede installierte Anwendung von einem verifizierten Entwickler registriert sein.
Und genau an dieser Stelle wurde aus einer Sicherheitsfunktion eine grundsätzliche Frage.
Warum muss sich ein F-Droid-Entwickler bei Google registrieren?
Nehmen wir einen kleinen Entwickler.
Er entwickelt in seiner Freizeit eine Open-Source-App.
Den Quellcode veröffentlicht er frei zugänglich.
Er möchte seine App nicht im Google Play Store anbieten.
Er möchte keinen Google-Dienst dafür verwenden.
Vielleicht erscheint seine Anwendung ausschließlich bei F-Droid.
Warum sollte dieser Entwickler seine Identität trotzdem gegenüber Google nachweisen müssen?
Genau hier liegt einer der zentralen Kritikpunkte.
Denn Google ist dann nicht mehr nur Betreiber des eigenen App-Stores.
Google wird zu einer Instanz, die innerhalb zertifizierter Android-Geräte entscheidet, ob eine außerhalb von Google Play bezogene Software als registriert gilt.
F-Droid reagierte darauf entsprechend deutlich.
Das Projekt erklärte im September 2025, dass es seine Entwickler nicht dazu zwingen könne und wolle, ihre Apps bei Google registrieren zu lassen. Gleichzeitig könne F-Droid nicht einfach selbst die Paketnamen fremder Open-Source-Projekte beanspruchen.
F-Droid bezeichnete die ursprüngliche Ausgestaltung deshalb als existenzielle Bedrohung für sein bisheriges Distributionsmodell.
Und damit kommen wir zu einer interessanten Entwicklung.
Denn Google blieb nicht bei seinem ursprünglichen Modell.
Dann ruderte Google zurück
Am 19. März 2026 veröffentlichte Google einen weiteren Beitrag.
Der Titel war bereits bemerkenswert:
„Balancing openness and choice with safety“
Also sinngemäß:
Offenheit und Wahlfreiheit mit Sicherheit in Einklang bringen.
Google erklärte darin, dass man seit Bekanntgabe der neuen Verifikationsanforderungen mit der Community gearbeitet habe.
Und plötzlich gab es eine Möglichkeit, die in der ursprünglichen Ankündigung so noch nicht vorgesehen war:
den Advanced Flow.
Damit sollen sogenannte „Power User“ weiterhin Anwendungen von nicht verifizierten Entwicklern installieren können.
Das ist eine wesentliche Änderung.
Aus:
Nicht registriert – nicht installierbar
wurde:
Nicht registriert – installierbar, wenn der Nutzer bewusst einen zusätzlichen Sicherheitsprozess durchläuft.
Man kann das durchaus als Zurückrudern bezeichnen.
Google selbst würde es vermutlich eher als Weiterentwicklung aufgrund von Feedback beschreiben. In späteren Veröffentlichungen verweist das Unternehmen ausdrücklich auf Rückmeldungen von Entwicklern, Nutzern und der Android-Community.
Die Installationsfreiheit bleibt damit grundsätzlich erhalten.
Allerdings mit einer interessanten Definition von Freiheit.
24 Stunden warten, um eine App zu installieren
Der von Google vorgesehene Advanced Flow funktioniert nicht einfach über einen zusätzlichen Schalter mit der Beschriftung:
„Ich weiß, was ich tue.“
Google hat mehrere Hürden eingebaut.
Nach der aktuellen Dokumentation muss der Nutzer zunächst die Entwickleroptionen aktivieren.
Danach muss bestätigt werden, dass niemand den Nutzer gerade dazu überredet oder unter Druck setzt, die Sicherheitsfunktion abzuschalten.
Anschließend wird das Smartphone neu gestartet und der Nutzer muss sich erneut authentifizieren.
Dann kommt der bemerkenswerteste Teil:
eine Wartezeit von einem Tag beziehungsweise 24 Stunden.
Erst danach kann die Installation nicht verifizierter Anwendungen freigegeben werden.
Der Nutzer kann diese Möglichkeit anschließend für sieben Tage oder unbegrenzt aktivieren.
Bei der Installation erscheint weiterhin eine Warnung, die aber mit „Install Anyway“ übergangen werden kann.
Google erklärt diese 24-Stunden-Sperre mit sogenannten Coercion Scams.
Dabei werden Opfer beispielsweise während eines Telefonats unter Druck gesetzt und Schritt für Schritt dazu gebracht, Sicherheitsfunktionen abzuschalten und eine schädliche Anwendung zu installieren.
Die Wartezeit soll diesen Zeitdruck unterbrechen.
Aus Sicherheitsperspektive lässt sich diese Argumentation nachvollziehen.
Aus Sicht digitaler Souveränität entsteht trotzdem eine ziemlich interessante Frage:
Warum muss ich 24 Stunden warten, bevor ich auf meinem eigenen Gerät eine Software installieren darf, deren Entwickler sich nicht bei Google registriert hat?
Offen – aber nur für „Power User“?
Genau an dieser Stelle wird die Diskussion schwierig.
Denn Google sagt ausdrücklich:
Android bleibt offen.
Alternative App-Stores können weiterhin verwendet werden.
Entwickler können Anwendungen weiterhin über Webseiten oder andere Vertriebswege anbieten.
Und Nutzer können auch Anwendungen nicht verifizierter Entwickler installieren.
Das stimmt nach dem aktuellen Konzept.
Aber die Erfahrung wird unterschiedlich.
Eine registrierte Anwendung:
Installieren.
Eine nicht registrierte Anwendung:
Entwickleroptionen aktivieren.
Bestätigung durchführen.
Smartphone neu starten.
Authentifizieren.
24 Stunden warten.
Erneut bestätigen.
Warnhinweis akzeptieren.
Installieren.
Die Möglichkeit existiert also weiterhin.
Aber sie wird bewusst unbequem gemacht.
Google nennt das Sicherheit.
Kritiker nennen es Gatekeeping.
Und wahrscheinlich liegt genau dort die eigentliche Debatte.
Keep Android Open
Aus der Kritik an Googles Plänen ist unter anderem die Initiative Keep Android Open entstanden.
Die Kampagne argumentiert, dass Google durch die Developer Verification eine zentrale Kontrollposition über Software erhält, die überhaupt nicht über Google Play vertrieben wird.
Keep Android Open begrüßt den Advanced Flow deshalb auch nicht als vollständige Lösung.
Die Initiative kritisiert insbesondere die zahlreichen notwendigen Schritte und die 24-stündige Wartezeit.
Dabei sollte man allerdings sauber unterscheiden:
Keep Android Open ist eine Kampagne gegen Googles Vorhaben und keine neutrale Informationsquelle.
Ihre Aussagen sollten deshalb gemeinsam mit Googles eigenen Dokumenten betrachtet werden.
Und genau das macht die Sache interessant.
Man benötigt kaum Interpretationen von Dritten.
Die Veränderung lässt sich bereits anhand von Googles eigenen Veröffentlichungen nachvollziehen.
August 2025
Google kündigt an, dass auf zertifizierten Android-Geräten Apps künftig von verifizierten Entwicklern registriert sein müssen – unabhängig davon, ob sie über Google Play oder andere Wege verteilt werden.
März 2026
Google stellt nach Rückmeldungen einen Advanced Flow vor, mit dem Nutzer Apps nicht verifizierter Entwickler weiterhin installieren können.
Juni 2026
Google präzisiert die Einführung weiter und bestätigt ausdrücklich, dass nicht registrierte Anwendungen weiterhin über ADB oder den Advanced Flow installiert werden können.
August 2026
Nach Googles aktuellem Zeitplan soll der Advanced Flow im August 2026 weltweit für Power User eingeführt werden. Ein genaues weltweites Freischaltdatum nennt die derzeitige Dokumentation nicht.
30. September 2026
Die eigentliche Durchsetzung beginnt zunächst in:
Brasilien,
Indonesien,
Singapur und
Thailand.
Und auch hier ist inzwischen eine wichtige Einschränkung hinzugekommen:
Am 30. September betrifft die Durchsetzung zunächst nur bestimmte teilnehmende App-Stores.
Google nennt Google Play sowie die Stores von Honor, Oppo/OPlus, Samsung, Transsion, vivo und Xiaomi.
F-Droid gehört nicht zu dieser ersten Gruppe.
Auch direkt heruntergeladene APKs und andere App-Stores fallen laut Googles FAQ am 30. September noch nicht unter diese erste Durchsetzungsphase.
Ab 2027
Google plant anschließend eine weltweite Ausweitung der Developer Verification auf zertifizierte Android-Geräte.
Der Advanced Flow soll dabei die Möglichkeit erhalten, weiterhin Software nicht verifizierter Entwickler zu installieren.
Das Smartphone gehört mir – oder?
Vielleicht ist genau das die interessantere Frage hinter der ganzen Diskussion.
Google verkauft die Developer Verification als Sicherheitsfunktion.
Und Teile dieser Argumentation sind durchaus nachvollziehbar.
Betrüger existieren.
Schadsoftware existiert.
Menschen werden tatsächlich dazu gebracht, gefährliche Anwendungen zu installieren.
Aber Sicherheit und Kontrolle liegen manchmal erstaunlich nah beieinander.
Und sobald ein zentraler Konzern festlegt, welche Voraussetzungen erfüllt sein müssen, bevor Software auf einem von mir gekauften Gerät installiert werden darf, sollte man zumindest darüber sprechen dürfen.
Denn mein Smartphone ist kein gemietetes Terminal eines App-Stores.
Ich habe es gekauft.
NoData // Souveränitätscheck
F-Droid ist deshalb für mich inzwischen mehr als nur ein alternativer App-Store.
Es zeigt, dass Softwareverteilung auch anders funktionieren kann.
Ohne Benutzerkonto.
Ohne den Zwang, jede Installation mit einer persönlichen Identität zu verbinden.
Mit Open Source.
Mit transparenten Hinweisen auf Tracking und andere unerwünschte Eigenschaften.
Und mit der grundsätzlichen Idee, dass der Besitzer eines Gerätes selbst entscheiden kann, welche Software darauf läuft.
Google nimmt uns diese Möglichkeit nach aktuellem Stand nicht vollständig.
Das sollte man fairerweise sagen.
Nach erheblicher Kritik wurde der Advanced Flow geschaffen und Apps nicht verifizierter Entwickler sollen weiterhin installierbar bleiben.
Aber allein die Tatsache, dass dafür künftig ein besonderer „Advanced“-Modus benötigt wird, zeigt, wie sich die Rollen verschieben.
Früher war die Frage:
Möchte ich diese App installieren?
Künftig könnte sie lauten:
Erlaubt mir die Plattform, diese App zu installieren – und welche Hürden muss ich dafür überwinden?
Vielleicht ist F-Droid deshalb gerade jetzt einen Blick wert.
Nicht unbedingt, um morgen den Play Store zu löschen.
Sondern um wieder ein Stück darüber nachzudenken, wem unser digitales Gerät eigentlich gehört.
Dem Hersteller?
Dem Plattformbetreiber?
Dem App-Store?
Oder vielleicht doch:
uns selbst.
Quellen
Google / Android – ursprüngliche Ankündigung vom 25. August 2025
A new layer of security for certified Android devices
Google kündigt die Developer Verification für Apps innerhalb und außerhalb des Play Stores an und beschreibt den ursprünglichen Zeitplan.
https://android-developers.googleblog.com/2025/08/elevating-android-security.html
Google / Android – Advanced Flow vom 19. März 2026
Android developer verification: Balancing openness and choice with safety
Hier kündigt Google die Möglichkeit an, dass Power User Apps nicht verifizierter Entwickler weiterhin installieren können. Außerdem beschreibt Google Entwickleroptionen, Neustart und die eintägige Wartezeit.
Google / Android – aktualisierter Rollout vom 18. Juni 2026
Android developer verification: Building a safer ecosystem together
Aktueller Zeitplan, Einführung des Android Developer Verifier, Advanced Flow, erste teilnehmende App-Stores und weltweite Ausweitung ab 2027.
Google / Android – offizielle FAQ
Frequently asked questions | Android developer verification
Die derzeit ausführlichste Google-Quelle zum Advanced Flow: 24-Stunden-Wartezeit, Installation nicht registrierter Apps, alternative App-Stores, ADB und aktuelle Einschränkungen der ersten Durchsetzungsphase.
https://developer.android.com/developer-verification/guides/faq
Google / Android – Developer Verification
Android developer verification
Zentrale Informationsseite zur Entwicklerregistrierung, Identitätsprüfung und zum geplanten weltweiten Rollout.
https://developer.android.com/developer-verification
F-Droid
F-Droid – Free and Open Source Android App Repository
Offizielle Projektseite und Informationen zum freien App-Ökosystem.
F-Droid – Datenschutz
No user accounts, by design
F-Droid erläutert, warum für die Auslieferung von Apps bewusst keine Benutzerkonten eingesetzt werden.
https://f-droid.org/2022/02/28/no-user-accounts-by-design.html
F-Droid – Anti-Features
Anti-Features
Dokumentation zur Kennzeichnung von Tracking, Werbung und anderen unerwünschten Eigenschaften.
https://f-droid.org/docs/Anti-Features/
F-Droid zur Google Developer Verification
F-Droid and Google's Developer Registration Decree
Stellungnahme von F-Droid zu den Auswirkungen der ursprünglich angekündigten Google-Regeln auf freie und unabhängige Softwareverteilung.
https://f-droid.org/2025/09/29/google-developer-registration-decree.html
Keep Android Open
Keep Android Open
Kampagne gegen Googles Developer-Verification-Modell mit eigener Bewertung des Advanced Flow. Die Seite ist als Interessenposition und nicht als neutrale Quelle zu verstehen.
Open Letter – Keep Android Open