Ein App-Store darf Regeln für seinen eigenen Katalog setzen. Ein Betriebssystemkonzern, der auch die Installierbarkeit außerhalb seines Stores an eine zentrale Registrierung bindet, tut etwas anderes: Er stellt den Türsteher nicht vor den Laden, sondern vor das Gerät.
Google beginnt laut aktueller Entwicklerdokumentation am 30. September 2026 mit der regionalen Durchsetzung seiner Android-Entwicklerverifizierung. Zunächst genannt werden Brasilien, Indonesien, Singapur und Thailand; ein weiterer weltweiter Ausbau ist ab 2027 angekündigt. Apps auf zertifizierten Android-Geräten sollen einem verifizierten Entwickler zugeordnet sein – ausdrücklich auch dann, wenn sie nicht aus Google Play kommen.
Das ist kein weltweites Sideloading-Verbot am 30. September. Es ist aber der Aufbau einer zentralen Kontrollschicht über alternative App-Verteilung. Für F-Droid trifft diese Schicht den Kern des eigenen Modells.
Was belegt ist – und was nicht
Google kündigte die Entwicklerverifizierung im August 2025 als Sicherheitsmaßnahme an. Das Unternehmen will wiederkehrende Betrüger und Schadakteure stärker an eine überprüfte Identität binden. Die Registrierung soll nicht nur den Play Store betreffen, sondern Apps aus anderen Stores und aus direkter Verteilung auf zertifizierten Android-Geräten.
Google beschreibt das Verfahren selbst als Identitätskontrolle, nicht als inhaltliche App-Prüfung. Das ist eine wichtige Grenze: Verifiziert wird zunächst, wer eine App registriert. Nicht bewiesen wird damit, dass ihr Quellcode sicher ist oder ihr Binärpaket tatsächlich aus einem veröffentlichten Quellstand entstand.
Die Durchsetzung beginnt nach aktueller Dokumentation regional. Deutschland gehört nicht zur ersten Ländergruppe. Deshalb sind Schlagzeilen wie „Ab 30. September ist F-Droid weltweit tot“ sachlich falsch. Ebenfalls nicht belastbar bestätigt ist eine pauschale Android-Versionsgrenze. Belegt ist die Kategorie „certified Android devices“.
Offen bleibt am 4. August, welche Stores und Installationswege zum Start praktisch erfasst werden, wie Updates bereits installierter unregistrierter Apps behandelt werden und welche Systemkomponente die Regel auf unterschiedlichen Geräten durchsetzt. Diese Fragen bleiben für die weitere Beobachtung offen. Die drei zentralen Primärquellen waren unmittelbar vor der Veröffentlichung weiterhin erreichbar.
Der Advanced Flow: Ausnahme mit eingebauter Abschreckung
Nach Kritik kündigte Google im März 2026 einen „Advanced Flow“ an. Technisch erfahrene Nutzer sollen damit weiterhin Apps nicht verifizierter Entwickler installieren können. Nach Googles Beschreibung gehören dazu:
- Entwicklermodus aktivieren,
- bestätigen, nicht von einer anderen Person angeleitet zu werden,
- das Telefon neu starten,
- sich erneut authentifizieren,
- einmalig einen Tag warten,
- Installationen für sieben Tage oder unbefristet erlauben.
Eine Warnung bleibt bestehen. Der Ablauf soll Telefonbetrug und Social Engineering erschweren: Neustart und Wartezeit unterbrechen Fernanleitung und künstlichen Zeitdruck. Das ist ein legitimes Sicherheitsziel.
Trotzdem verändert der Ablauf die Bedeutung von Wahlfreiheit. Eine nicht registrierte App ist nicht mehr ein normaler Installationsfall, über den der Eigentümer nach einer verständlichen Warnung entscheidet. Sie wird zum Expertenfall mit absichtlich eingebauter Reibung. Dass eine dauerhafte Freischaltung angekündigt ist, verhindert ein Totalverbot. Es stellt aber keine Gleichwertigkeit der Vertriebswege her.
Für Hobbyentwickler ist zusätzlich ein kostenloses Modell ohne amtlichen Identitätsnachweis und Gebühr vorgesehen. Es ist auf höchstens zwanzig ausdrücklich autorisierte Geräte begrenzt. Für eine Lerngruppe kann das reichen. Für einen öffentlichen freien App-Store, einen Verein oder eine Community mit wechselnden Mitgliedern ist diese Ausnahme keine Lösung.
Warum F-Droid anders vertraut
F-Droid ist nicht bloß ein zweiter Play Store mit anderem Logo. Das Projekt veröffentlicht freie Software über eine eigene Metadaten- und Build-Pipeline. Regulär wird eine App aus dem angegebenen Quellcode gebaut und mit einem F-Droid-Schlüssel signiert. Dokumentierte Anti-Features machen beispielsweise Werbung, Tracking oder unfreie Abhängigkeiten sichtbar.
Bei reproduzierbaren Builds kann F-Droid eine upstream-signierte APK gegen einen eigenen Nachbau prüfen. Stimmen die Pakete kryptografisch überein, beschreibt die technische Dokumentation einen Weg für die Veröffentlichung mit der ursprünglichen Signatur. Das garantiert weder fehlerfreien Code noch einen reproduzierbaren Build für jede App. Es schafft aber einen überprüfbaren Zusammenhang zwischen Quellcode, Buildprozess und ausgeliefertem Paket.
Googles Modell beantwortet eine andere Frage: Welche registrierte Identität darf welche Paketkennung verteilen? Genau diese Verbindung kollidiert mit F-Droid. Das Projekt kann nicht alle Upstream-Entwickler zwingen, sich bei Google zu registrieren. Es kann die Paketkennungen fremder Projekte auch nicht einfach selbst beanspruchen, ohne eine zentrale Vertriebsrolle für Software einzunehmen, die ihm nicht gehört.
F-Droid nennt die Regel daher eine existenzielle Bedrohung für seine bisherige Arbeitsweise. Das ist die Position eines direkt betroffenen Projekts, kein neutraler Beweis für ein bereits feststehendes Ende. Die strukturelle Kollision ist dennoch real: Ein dezentrales Build- und Signaturmodell trifft auf ein zentrales Identitäts- und Paketregister.
Entwickleridentität ersetzt keine Softwareprüfung
Googles Sicherheitsargument ist nicht erfunden. Wer Betrugs-Apps unter ständig wechselnden Namen verbreitet, kann durch eine Identitätsbindung leichter verfolgt und ausgeschlossen werden. Google verweist außerdem auf eine eigene Analyse, nach der Internet-Sideloading-Quellen mehr als fünfzigmal so viel Malware enthielten wie Google Play.
Belegt ist, dass Google diese Zahl nennt. Die abgerufene Veröffentlichung legt Methodik, Stichprobe und Vergleichsdefinition jedoch nicht so offen, dass die Zahl unabhängig reproduziert werden könnte. Sie muss daher als Konzernangabe bezeichnet werden, nicht als neutraler Messwert.
Vor allem prüft eine Identität nicht den Code. Ein bekanntes Entwicklerkonto kann übernommen werden. Eine legitime App kann später eine kompromittierte Bibliothek einbauen. Ein registriertes Binärpaket kann Funktionen enthalten, die im veröffentlichten Quellcode nicht sichtbar sind. Signaturen, nachvollziehbare Builds, Berechtigungskontrollen und transparente Updateketten bleiben notwendig.
Die Debatte darf deshalb nicht auf „Registrierung oder Chaos“ verkürzt werden. Es gibt weitere Schutzmechanismen: abgestufte Warnungen, lokale Prüfungen, transparente Signaturinformationen, reproduzierbare Builds, föderierte Vertrauenslisten und einen klaren Eigentümerentscheid. Keine dieser Maßnahmen ist allein perfekt. Gerade das spricht gegen einen zentralen Registerpunkt als universelle Lösung.
Die eigentliche Macht liegt in der Paketkennung
Die politische Machtverschiebung entsteht aus der Kombination von Entwickleridentität, Paketkennung und Installierbarkeit. Wer diese Verbindung kontrolliert, entscheidet nicht nur, wer in einem Store sichtbar ist. Er entscheidet, welcher Anbieter Software unter welchem Namen normal auf einem Gerät verteilen darf.
Heute wird dieser Punkt mit Betrugsabwehr begründet. Dieselbe Infrastruktur kann künftig Gebühren, Vertragsbedingungen, regionale Sperren oder politische Vorgaben durchsetzen. Das ist keine Behauptung, dass Google all diese Möglichkeiten einsetzen wird. Es ist eine Analyse dessen, was eine zentrale Kontrollarchitektur technisch und wirtschaftlich ermöglicht.
Apple liefert in der EU ein warnendes Vergleichsbild. Alternative App-Marktplätze sind dort grundsätzlich möglich, bleiben aber an Apple-Autorisierung, Notarisierung, Entitlements und erhebliche Betreiberanforderungen gebunden. Das beweist nicht, dass Google Apples Modell kopiert. Es zeigt, dass „Alternative erlaubt“ und „Alternative unabhängig“ zwei sehr verschiedene Aussagen sind.
Konkrete Folgen für freie Communities
Eine kleine Matrix-Community kann einen angepassten Client für Moderation und Raumverwaltung bauen. Sie kann den Quellcode veröffentlichen, die APK signieren und über ein eigenes F-Droid-Repository verteilen. Mit der neuen Kontrollschicht kann auf zertifizierten Geräten trotzdem eine Google-Registrierung zum zusätzlichen Engpass werden.
Ein Selfhosting-Projekt kann eine kleine App für Backup-Status oder Token-Widerruf bereitstellen. Zwanzig Testgeräte reichen vielleicht während der Entwicklung. Sie reichen nicht, wenn Administratoren, Helfer, Ersatzgeräte und eine offene Nutzergemeinschaft versorgt werden sollen.
Die Hürde trifft damit nicht nur unbekannte APK-Portale. Sie trifft auch Software, deren Quellcode offenliegt, deren Build dokumentiert ist und deren Nutzer den Anbieter bewusst gewählt haben. Eine identische Warn- und Sperrlogik behandelt unterschiedliche Vertrauenssituationen gleich.
Bewertung: Schutz ja, Konzernpassamt nein
Eigene redaktionelle Bewertung: Google benennt ein reales Problem. Social Engineering und Schadsoftware außerhalb kuratierter Stores verdienen wirksame Gegenmaßnahmen. Eine zentrale Registrierung kann die Kosten für wiederholten Missbrauch erhöhen.
Die Machtkonzentration geht dennoch zu weit. Ein Konzern sollte nicht zugleich das dominante Betriebssystemökosystem, einen zentralen Store, die Entwickleridentität, die Paketzuordnung und den normalen Installationsweg kontrollieren. Sicherheit darf Entscheidungen des Eigentümers informieren und in nachweisbaren Risikosituationen erschweren. Sie darf nicht aus freier Software einen genehmigungspflichtigen Sonderfall machen.
Der Advanced Flow bewahrt eine Restfreiheit. Aber eine Freiheit hinter Entwicklermodus, Belehrung, Neustart und Wartefrist ist praktisch schwächer als ein normaler Eigentümerentscheid. Vor allem bleibt dieser Weg von Google gestaltet und jederzeit veränderbar.
Fazit: Offenheit braucht einen normalen Weg
F-Droid ist am 30. September nicht automatisch tot. Sideloading wird nicht weltweit mit einem Schalter abgeschafft. Solche Übertreibungen helfen nur Google, berechtigte Kritik als Panik abzutun.
Der belastbare Befund ist schärfer: Google baut eine Kontrollschicht auf, die über den eigenen Store hinausreicht. Sie bindet normale Installierbarkeit an eine zentrale Zuordnung von Entwickleridentität und Paketkennung. F-Droids Modell aus freiem Quellcode, eigener Build-Pipeline und unabhängiger Signatur passt nicht sauber in dieses Register.
Digitale Souveränität bedeutet nicht, Warnungen abzuschaffen. Sie bedeutet, dass nach einer verständlichen Warnung die letzte Entscheidung beim Eigentümer liegt. Ein Smartphone gehört dir nicht vollständig, wenn der Konzern nach dem Kauf bestimmt, welcher Entwickler darauf normal Software verteilen darf.
Offene Prüfpunkte für die weitere Beobachtung
- allgemeine Verfügbarkeit und endgültige Oberfläche des Advanced Flow
- exakte Länder-, Store-, Geräte- und Updateabdeckung
- technische Komponente der Durchsetzung auf zertifizierten Geräten
- aktueller F-Droid-Plan für Bestands-Apps, Signaturen und Paketkennungen
- amtliche Stellungnahmen oder Verfahren europäischer Behörden
Quellen
- Google, Android Developers Blog: „A new layer of security for certified Android devices“
https://android-developers.googleblog.com/2025/08/elevating-android-security.html
- Google, Android Developers Blog: „Balancing openness and choice with safety“
https://android-developers.googleblog.com/2026/03/android-developer-verification.html
- Google, Android Developers: „Developer verification“
https://developer.android.com/developer-verification
- F-Droid: „F-Droid and Google’s Developer Registration Decree“
https://f-droid.org/2025/09/29/google-developer-registration-decree.html
- F-Droid-Dokumentation: „Reproducible Builds“
https://f-droid.org/en/docs/Reproducible_Builds/
- Apple Developer Support: „Getting started as an alternative app marketplace in the European Union“
https://developer.apple.com/support/alternative-app-marketplace-in-the-eu/
- Europäische Kommission: „DMA designated Gatekeepers“
https://digital-markets-act.ec.europa.eu/gatekeepers-portal_en
CTA
Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/
Wenn dir das Projekt hilft: Spendenlinks sind im Blog.
