Android Entwickler-Verifizierung: euer Gerät ist egal

Seit Juni 2026 läuft auf hunderten Millionen Android-Geräten ein Systemdienst, der vor jeder Installation nachschlägt, ob der Entwickler einer App bei Google registriert ist. Er tut noch nichts. Am 30. September fängt er in vier Ländern damit an. Die Android Entwickler-Verifizierung ist damit von einer Ankündigung zu einer Infrastruktur geworden, die bereits auf euren Telefonen sitzt — und die Debatte darüber führt in eine falsche Richtung, weil sie sich um Geräte dreht. Als wir im Februar über die Kampagne Keep Android Open und Googles Pläne, Android zu schliessen geschrieben haben, war vieles davon noch Absichtserklärung. Inzwischen gibt es Termine, Preise, Kontotypen und ein Kartellurteil. Zeit für eine Zwischenbilanz — und für die unangenehme These, dass ein Custom-ROM euch aus dieser Sache nur begrenzt heraushilft.

Was die Android Entwickler-Verifizierung seit Februar tatsächlich geworden ist

Googles eigener Fahrplan steht seit Juni auf dem Android Developers Blog und in der Entwicklerdokumentation. Er ist bemerkenswert unspektakulär formuliert, und genau das lohnt sich anzusehen.

Im Juni 2026 hat Google einen neuen Systemdienst ausgerollt, den Android Developer Verifier. Er läuft laut Dokumentation auf allen zertifizierten Android-Geräten ab Android 7. Im Juli kamen die Programmierschnittstellen dazu: eine Status-Abfrage für Entwickler-IDs und ein früher Zugang zur Konsolen-Schnittstelle, mit der sich Registrierungen aus einer Build-Pipeline heraus in grosser Zahl anlegen lassen. Im August 2026 — also jetzt — schaltet Google die Limited Distribution Accounts und den sogenannten Advanced Flow weltweit frei. Und am 30. September 2026 wird die Registrierung erstmals erzwungen: in Brasilien, Indonesien, Singapur und Thailand, bei den teilnehmenden Stores. Das sind Google Play, der HONOR App Market, der OPPO App Market, der Samsung Galaxy Store, der Palm Store von Transsion, der V-Appstore von vivo und Xiaomis GetApps. Für 2027 und danach kündigt Google die weltweite Ausdehnung auf alle zertifizierten Android-Geräte an.

Am 30. September passiert weniger, als die Schlagzeilen sagen

Hier lohnt sich Genauigkeit, weil an dieser Stelle viel Unsinn kursiert. Der Stichtag im September beendet das Sideloading nicht. Googles eigene FAQ sagt es klar: Wer seine App über andere Stores verteilt oder wessen Nutzer die App direkt sideloaden, für den gelten die neuen Anforderungen "noch nicht". Das entscheidende Wort ist "noch". Was am 30. September greift, betrifft die oben genannten Stores in vier Ländern.

Wer daraus Entwarnung liest, hat den Aufbau nicht verstanden. Der Verifier ist bereits verteilt. Die Registrierungsschnittstellen sind bereits offen. Die Kontotypen sind bereits definiert. Was 2027 folgt, ist kein neues Projekt, sondern das Umlegen eines Schalters an einem System, das dann seit anderthalb Jahren läuft und eingespielt ist. Der September ist der Feldtest, nicht das Ziel.

Der Advanced Flow ist das eigentliche Druckmittel — und Google sagt nicht, was er verlangt

Für alle, die trotzdem Apps unverifizierter Entwickler installieren wollen, hat Google den Advanced Flow angekündigt. In der offiziellen Hilfeseite steht dazu genau ein Satz: Nutzer könnten die Risiken akzeptieren, indem sie "einen einmaligen Advanced Flow durchlaufen, der aufklärende Sicherheitsschritte enthält". Mehr nicht. Keine Beschreibung der Schritte, keine Angabe zu Wartezeiten, kein Hinweis darauf, ob ein Neustart oder eine erneute Anmeldung nötig ist.

In der Fachpresse kursieren Beschreibungen, wonach der Ablauf das Aktivieren des Entwicklermodus, einen Neustart, eine Wartezeit von 24 Stunden und eine erneute Authentifizierung umfassen soll. Diese Angaben lassen sich in Googles eigener Dokumentation nicht nachprüfen, und deshalb stehen sie hier auch nicht als Tatsache. Bemerkenswert ist etwas anderes: Der Advanced Flow ist laut Googles Zeitplan seit diesem Monat weltweit aktiv, der erste Durchsetzungsstichtag liegt sechs Wochen entfernt — und die Firma beschreibt bis heute nicht öffentlich, was Nutzer konkret tun müssen, um eine App zu installieren, die sie installieren wollen. Ein Unternehmen, das eine Hürde als Sicherheitsgewinn verkauft, dürfte kein Problem damit haben, diese Hürde zu beschreiben.

Das ist kein Detail. Ob eine Nutzerentscheidung zwei Klicks kostet oder einen Tag Wartezeit, entscheidet darüber, ob sie in der Praxis getroffen wird. Wer schon einmal beobachtet hat, wie viele Leute an "Installation aus unbekannten Quellen zulassen" scheitern, weiss, wie wenig Reibung nötig ist, um eine Möglichkeit faktisch abzuschaffen, ohne sie formal zu verbieten.

20 Geräte sind kein Zugeständnis, sondern eine Definition

Auf die Kritik der letzten Monate hat Google mit einer Abstufung reagiert. Es gibt jetzt zwei Kontotypen. Der Full Distribution Account kostet 25 US-Dollar einmalig und verlangt einen amtlichen Ausweis. Der Limited Distribution Account ist kostenlos, verlangt keinen Ausweis — und erlaubt die Verteilung an höchstens 20 Geräte. Google beschreibt ihn als Angebot für "Studenten, Hobbyisten und Lernende". Organisationen brauchen zusätzlich eine D-U-N-S-Nummer von Dun & Bradstreet; die ist gratis, ihre Ausstellung dauert aber bis zu 28 Tage.

Das wurde vielfach als Einlenken gelesen. Es ist das Gegenteil. Mit der 20-Geräte-Grenze definiert Google, wo Hobby aufhört und Verteilung anfängt — und zieht diese Linie so, dass praktisch jedes ernstzunehmende freie Projekt auf der falschen Seite landet. Eine App mit fünfzig Nutzern ist kein Hobby mehr. Der Entwickler eines kleinen Matrix-Clients, einer Wallet-Erweiterung oder eines Werkzeugs für die eigene Community wird nicht deshalb zum kommerziellen Marktteilnehmer, weil hundert Leute das Ding installiert haben. Für Google ist er es ab Gerät einundzwanzig.

Und dann ist da der Ausweis. Für einen Entwickler in Zürich mag das eine Formalität sein. Für jemanden, der ein Umgehungswerkzeug für ein autoritär regiertes Land pflegt, ist es das Ende der Beteiligung. Pseudonymität ist in freier Software kein Schlupfloch, sondern eine Arbeitsbedingung. Genau deshalb funktionieren Signaturprüfungen wie die Verifikation über ASC-Signaturen auch ohne Klarnamen: Sie beantworten die Frage "stammt dieses Paket von derselben Quelle wie das letzte", und nur die ist für Sicherheit relevant.

Der Hebel liegt beim Entwickler, nicht bei eurem Gerät

Damit sind wir beim Kern. Registriert wird nicht euer Telefon, registriert wird das Paket: Package Name und Signaturschlüssel, gebunden an eine verifizierte Identität. Wer Google Play App Signing nutzt, dessen Apps übernimmt Google automatisch in dieses Register. Diese Bindung ist kanalunabhängig. Sie hängt nicht daran, woher die APK-Datei kommt, sondern daran, ob es zu Package Name und Schlüssel einen registrierten Menschen gibt.

Der praktische Effekt: Google muss euer Gerät gar nicht kontrollieren. Es reicht, wenn der Markt der zertifizierten Geräte gross genug ist, dass sich kein Entwickler leisten kann, dort nicht zu erscheinen. Wer sich registriert, um seine App weiter an drei Milliarden Android-Nutzer ausliefern zu können, hat damit dieselbe Identität an dasselbe Register gehängt, das für jeden anderen Kanal gilt. Wer sich weigert, verschwindet aus dem Play Store und behält seine Nische. Beides sind Entscheidungen, die der Entwickler trifft — nicht ihr.

Custom-ROMs bleiben frei, und das ist die schlechtere Nachricht, als sie klingt

Technisch gilt die Verifizierung ausschliesslich für zertifizierte Android-Geräte. Das GrapheneOS-Projekt hat das im eigenen Forum knapp festgehalten: "It's not relevant to GrapheneOS. GrapheneOS does not have Google Mobile Services and rules for Google certified operating systems don't apply to it." Dasselbe gilt für CalyxOS, LineageOS und jeden anderen AOSP-Bau. Auch ADB bleibt ausgenommen; wer per Kabel installiert, ist von alldem nicht betroffen.

Das ist echt und es ist wichtig. Es ist aber kein Schutzraum, sondern eine Auffangvorrichtung. Ein Gerät mit GrapheneOS garantiert euch, dass euch niemand an der Installation hindert. Es garantiert nicht, dass es etwas zu installieren gibt. Wenn der Entwickler eines Werkzeugs, das ihr nutzt, in zwei Jahren entscheidet, dass er seinen Pass nicht bei Google hinterlegt, und deshalb die Android-Version einstellt, dann hilft euch euer offenes Betriebssystem exakt nichts. Ihr habt dann ein Telefon, auf dem ihr alles installieren dürft, und nichts mehr, was ihr installieren wollt.

Das ist der Grund, warum die verbreitete Beruhigung "betrifft uns nicht, wir haben eh ein Custom-ROM" in die Irre führt. Sie verwechselt die Freiheit, etwas zu tun, mit der Existenz dessen, was ihr tun möchtet. Wir haben diesen Mechanismus schon bei Googles Verschärfungen bei den Pixel-Geräten gesehen und in grösserem Zusammenhang bei der Frage, wie die Fassade der Offenheit bei Android bröckelt: Die Sperre kommt nie über das Gerät, sie kommt über das, was um das Gerät herum verschwindet.

Warum F-Droids Warnung diesmal keine Übertreibung ist

F-Droid formuliert seit Herbst 2025 sehr direkt, dass das Projekt in dieser Form nicht überleben würde. Im Originalwortlaut: "the developer registration decree will end the F-Droid project and other free/open-source app distribution sources as we know them today". Das klingt nach Alarmrhetorik, ist aber strukturell begründet. F-Droid baut und signiert Apps selbst — genau der Punkt, den wir in unserem Artikel zu den Sicherheitsbedenken bei F-Droid kritisch beleuchtet haben. Im neuen Modell ist das ein Problem: F-Droid kann Entwickler nicht zwingen, sich bei Google registrieren zu lassen, und kann die Package Names auch nicht selbst beanspruchen, ohne sich Verteilungsrechte anzumassen, die ihm nicht zustehen.

Im Februar 2026 hat F-Droid deshalb zusammen mit der Electronic Frontier Foundation, der Free Software Foundation Europe und der Software Freedom Conservancy einen offenen Brief veröffentlicht, der Entwickler auffordert, sich nicht zu registrieren. Die Kampagne Keep Android Open zählt inzwischen 71 Organisationen aus 23 Ländern, darunter das Tor-Projekt, Nextcloud, KDE, die GNOME Foundation und LineageOS, dazu über 100'000 Unterschriften unter einer Petition. Das ist für Verhältnisse der freien Softwarewelt eine ungewöhnlich breite Front.

Das Kartellurteil vom 2. Juli traf ein Geschäftsmodell, das Google gerade ersetzt

Am 2. Juli 2026 hat der Gerichtshof der Europäischen Union in der Rechtssache C-738/22 P das Rechtsmittel von Google und Alphabet zurückgewiesen und die Geldbusse von rund 4,125 Milliarden Euro bestätigt, davon 1,52 Milliarden gesamtschuldnerisch für Alphabet. Bestraft wurden drei Praktiken: Vorinstallationsbedingungen für Google Search und Chrome als Preis für den Play-Store-Zugang, Umsatzbeteiligungen gegen die Vorinstallation konkurrierender Suchdienste, und Anti-Fragmentierungsvereinbarungen, mit denen sich Hersteller verpflichteten, "keine Geräte zu verkaufen, die mit nicht von Google zugelassenen Versionen des Betriebssystems Android ausgestattet sind".

Acht Jahre hat dieses Verfahren gedauert. Es ging um Verträge: darum, was Google Geräteherstellern vorschreiben durfte. Und während es lief, hat Google den Hebel gewechselt. Die Entwickler-Verifizierung braucht keine Verträge mit Herstellern. Sie braucht einen Systemdienst und ein Register. Die Free Software Foundation Europe hat das Ende Juli auf den Punkt gebracht: Google verlagere seine Kontrolle von Verträgen hin zur Beherrschung von Ökosystem und Interoperabilität. Ein Bussgeld von 4,125 Milliarden Euro ist für Alphabet eine Position in der Quartalsrechnung. Ein Register, das jede Android-App an eine verifizierte Identität bindet, ist ein Strukturvorteil auf Jahrzehnte.

Brüssel hat gefragt und bislang keine Antwort bekommen

Im EU-Parlament liegt die Frage seit Monaten auf dem Tisch. Christel Schaldemose hat am 8. April 2026 eine schriftliche Anfrage an die Kommission gerichtet, die drei Dinge wissen will: ob eine zentrale Registrierungs- und Verifizierungspflicht für alle Android-Entwickler mit dem Digital Markets Act vereinbar ist, ob die Kommission darin eine Einschränkung von Sideloading und Drittanbieter-Stores sieht, und wie sie sicherstellen will, dass Sicherheitsanforderungen nicht zur Umgehung des DMA benutzt werden. Bereits am 9. März 2026 hatten sechs Abgeordnete der Fraktion Renew eine Anfrage zum selben Themenkreis eingereicht. Eine Antwort der Kommission ist zu keiner der beiden veröffentlicht.

Das ist die eigentlich beunruhigende Zahl in diesem Text. Vier Monate für eine Frage, deren Beantwortung darüber entscheidet, ob der wichtigste Hebel der europäischen Plattformregulierung auf den Vorgang überhaupt anwendbar ist — während Google parallel den Systemdienst ausrollt, die Schnittstellen öffnet und einen Stichtag setzt. Regulierung, die langsamer ist als der Rollout, den sie prüfen soll, reguliert nichts.

Die Schweiz hat nicht einmal die Frage

Für Leser in der Schweiz kommt eine unangenehme Ebene dazu: Der Digital Markets Act gilt hier nicht. Es gibt keine Vorschrift, die Google zwingt, in der Schweiz dasselbe anzubieten wie im EWR. Und Google nutzt das nachweislich aus.

Am 14. Juli 2026 hat das Sekretariat der Wettbewerbskommission eine Vorabklärung gegen Google eröffnet. Der Anlass: Google hat den sogenannten Choice Screen bei der Ersteinrichtung von Android-Geräten in der Schweiz abgeschafft — jene Auswahl, mit der Nutzer ihre Standardsuchmaschine selbst bestimmen. In der EU besteht die Auswahl weiter, weil sie dort vorgeschrieben ist. Die WEKO hält fest, der Choice Screen solle "Abschottungseffekte durch Voreinstellungen verringern", und prüft nun, ob die Abschaffung eine unzulässige Wettbewerbsbeschränkung nach Kartellgesetz darstellt.

Das ist ein Lehrstück, und zwar ein aktuelles. Es zeigt in einem konkreten, überprüfbaren Fall, was Google mit einem Markt macht, in dem es nicht muss: Es nimmt die Wahlmöglichkeit weg. Wer glaubt, bei einer künftigen Ausnahmeregelung zur Entwickler-Verifizierung — etwa erzwungen durch den DMA — würde die Schweiz automatisch mitprofitieren, sollte sich diesen Vorgang genau ansehen. Es gibt nichts, das automatisch mitprofitiert. Eine Vorabklärung ist zudem noch keine Untersuchung und erst recht keine Verfügung; sie klärt nur, ob es überhaupt Anhaltspunkte gibt.

Die Gegenposition: Malware auf Android ist ein echtes Problem

Es wäre unredlich, das Sicherheitsargument abzutun. Betrug über sideloadete Apps ist in den vier Startländern kein Hirngespinst, sondern ein Massenphänomen mit realen Opfern. Wer in Indonesien oder Thailand über eine gefälschte Banking-App sein Erspartes verliert, hat wenig Interesse an Prinzipiendebatten über Softwarefreiheit. Googles Zahlen zum Malware-Aufkommen aus nicht überprüften Quellen haben wir im Februar-Artikel bereits eingeordnet und wiederholen sie hier nicht.

Der Einwand trägt trotzdem nicht, und zwar aus einem sehr technischen Grund: Identität ist keine Sicherheitseigenschaft. Ein Ausweis beim Anbieter beantwortet nicht die Frage, ob eine App schädlich ist. Er beantwortet die Frage, wen sich hinterher belangen lässt. Das ist ein legitimes Ziel der Strafverfolgung, aber es ist Betrugsbekämpfung mit den Mitteln der Zugangskontrolle — und es ist genau die Argumentationsfigur, die uns aus der Debatte um Altersverifikation und Klarnamenpflicht bekannt ist. Wer organisierten Betrug betreibt, kauft ein verifiziertes Konto oder benutzt einen gestohlenen Ausweis. Wer eine Kryptowallet für zweihundert Leute pflegt, hat diese Möglichkeit nicht.

Dazu kommt: Der Play Store ist bereits ein verifizierter Kanal, und Schadsoftware taucht dort regelmässig auf. Verifizierung hat das dort nie verhindert. Was Schadsoftware verhindert, sind Berechtigungsmodelle, Sandboxing, reproduzierbare Builds und Signaturketten — technische Massnahmen, an denen sich das Gerät orientieren kann, ohne zu wissen, wie der Entwickler heisst.

Was ihr tun könnt

• Rechnet nicht mit dem 30. September, sondern mit 2027. Wer heute eine App aus einer freien Quelle nutzt, sollte jetzt prüfen, ob es die Anwendung auch als Flatpak, als Web-Anwendung oder auf einem anderen Gerät gibt. Abhängigkeiten aufzulösen dauert länger als ein Wochenende.
• Legt euch ein Archiv eurer APK-Dateien an. Bereits installierte Apps sind von der Verifizierung nicht rückwirkend betroffen — Updates und Neuinstallationen dagegen schon. Eine lokale Kopie der letzten funktionierenden Version ist keine Paranoia, sondern Datensicherung.
• Nutzt Verteilwege, die nicht über einen Store laufen. Obtainium holt Apps direkt aus den Release-Seiten der Projekte. Das löst das Registerproblem nicht, hält aber die Zahl der Zwischenstationen klein und macht sichtbar, woher eine Datei tatsächlich kommt.
• Unterstützt die Entwickler, die ihr nutzt — mit Geld. Die 25 Dollar sind nicht das Problem, die Sichtbarkeitsanforderung ist es. Aber ein Projekt, das seine Nutzer kennt und von ihnen getragen wird, kann eine Grundsatzentscheidung überhaupt treffen. Ein Projekt, das von Play-Store-Reichweite lebt, kann es nicht.
• Schreibt an die Aufsicht, und zwar an die richtige. In der EU ist die zuständige Stelle die DMA-Einheit der Kommission. In der Schweiz ist es die Wettbewerbskommission, die mit der Choice-Screen-Vorabklärung gerade zeigt, dass sie sich für Googles Sonderbehandlung dieses Marktes interessiert. Eine sachliche Eingabe mit konkretem Bezug ist mehr wert als eine Unterschrift.
• Wechselt das Betriebssystem trotzdem. Ein Custom-ROM löst dieses Problem nicht, aber es löst die anderen. Und es sorgt dafür, dass ihr die Wahl noch habt, wenn es eng wird.

Fazit: Google braucht euer Gerät nicht, es braucht eure Entwickler

Die ganze Debatte um die Android Entwickler-Verifizierung dreht sich um die falsche Frage. Sie fragt, ob euer Telefon euch etwas verbietet. Die Antwort darauf ist beruhigend und irrelevant: Auf einem nicht zertifizierten Gerät verbietet euch niemand etwas, und daran wird sich absehbar nichts ändern.

Die richtige Frage lautet, wer künftig überhaupt noch Android-Software veröffentlichen kann, ohne einen Ausweis bei einem amerikanischen Konzern zu hinterlegen. Registriert wird nicht das Gerät, sondern das Paket. Und ein Register, das Package Name und Signaturschlüssel an eine amtlich geprüfte Identität bindet, wirkt in jedem Kanal, auch in denen, die Google formal gar nicht kontrolliert — weil der Entwickler nur eine Identität hat.

Der Gerichtshof hat acht Jahre gebraucht, um Google für Verträge zu bestrafen, die das Unternehmen inzwischen nicht mehr braucht. Das Parlament fragt seit April und bekommt keine Antwort. Die Schweiz hat nicht einmal das Gesetz, unter dem sich die Frage stellen liesse. Und in sechs Wochen läuft der erste Stichtag ab. Dass Custom-ROMs ausgenommen bleiben, ist unter diesen Umständen kein Sieg, sondern eine Fussnote: Es ist die Erlaubnis, in einem leeren Raum zu stehen und alles installieren zu dürfen, was es dann noch gibt.

Quellen und weiterführende Links

• Android Developers Blog: Android developer verification — Googles Zeitplan von Juni 2026
• developer.android.com: Developer verification — Meilensteine und betroffene Geräte
• developer.android.com: Verification FAQ — Kontotypen, Gebühren, Geltungsbereich
• Google-Hilfe: Apps von verifizierten Entwicklern installieren — die einzige öffentliche Beschreibung des Advanced Flow
• Gerichtshof der EU, Pressemitteilung zum Urteil C-738/22 P vom 2. Juli 2026 (PDF)
• Europäisches Parlament, schriftliche Anfrage E-001419/2026 von Christel Schaldemose
• Europäisches Parlament, schriftliche Anfrage E-000971/2026 zu Beschränkungen der App-Verteilung
• WEKO: Vorabklärung gegen Google zum Choice Screen, 14. Juli 2026
• F-Droid: Offener Brief gegen die Developer Verification
• F-Droid: Google's developer registration decree — die ursprüngliche Einschätzung des Projekts
• Keep Android Open — Kampagne, offener Brief und Unterstützerliste
• FSFE: Google Android antitrust ruling shows the next battle is over who controls trust, 28. Juli 2026
• GrapheneOS-Forum: New Google app developer identification requirements in 2026