Wie Google Android schliesst - die Entwickler-Verifizierung ab 2026

Was sich ab 2026 ändert

Android galt seit jeher als die offene Mobilplattform: Wer eine App baut, kann sie direkt an Nutzer verteilen - als APK, über einen alternativen Store wie F-Droid, ohne Googles Erlaubnis. Genau dieses Prinzip steht jetzt auf dem Spiel.

Am 25. August 2025 kündigte Google an, dass künftig alle Apps auf zertifizierten Android-Geräten von verifizierten Entwicklern registriert sein müssen - und zwar unabhängig vom Vertriebsweg. Die Pflicht gilt ausdrücklich auch für direkt installierte Apps und für Apps aus anderen Stores, nicht nur für den Play Store. Wer seine App ausserhalb von Google Play verteilt, muss sich trotzdem bei Google verifizieren, sonst lässt sich die App auf zertifizierten Geräten nicht mehr installieren.

Der Rollout läuft gestaffelt:

• August 2025 - Ankündigung der Verifizierungspflicht.
• März 2026 - Verifizierung öffnet für alle Entwickler in Play Console und Android Developer Console.
• April 2026 - der Systemdienst «Android Developer Verifier» beginnt auf Geräten zu erscheinen.
• August 2026 - der «advanced flow» für Power-User wird ausgerollt.
• September 2026 - erste Durchsetzung in Brasilien, Indonesien, Singapur und Thailand: nicht verifizierte Apps werden auf zertifizierten Geräten blockiert.
• 2027 - weltweite Ausweitung.

Es ist also keine Drohung, sondern ein laufender Umbau mit Terminplan. Die Kampagne Keep Android Open, hinter der 71 Organisationen aus 23 Ländern stehen - darunter F-Droid, die Electronic Frontier Foundation und die Free Software Foundation -, nennt das einen «retroaktiven» Umbau eines offenen Systems zu einem kontrollierten.

Wie die Verifizierungspflicht funktioniert

Der Hebel ist das Wort «zertifiziert». Googles Anforderungen gelten laut der offiziellen Dokumentation für certified Android devices - also Geräte, die Google für seine Dienste zertifiziert hat. Auf diesen Geräten prüft ein neuer Systemdienst bei jeder Installation, ob die App einem verifizierten Entwickler zugeordnet ist. Fehlt diese Zuordnung, verweigert das System die Installation - egal, woher die APK kommt.

Die Verifizierung selbst ist gestaffelt. Für Lehrpersonen, Studierende und Hobbyentwickler gibt es ein kostenloses Konto, mit dem sich Apps ohne amtlichen Ausweis und ohne Gebühr an bis zu 20 Geräte verteilen lassen. Wer darüber hinaus verteilen will, durchläuft die Standard-Verifizierung mit amtlichem Lichtbildausweis und einer einmaligen Gebühr von 25 US-Dollar.

Für den Fall, dass jemand eine nicht registrierte App installieren will, sieht Google einen «advanced flow» vor: Entwicklermodus aktivieren, eine Bestätigung gegen Nötigung, ein Neustart mit erneuter Authentifizierung, eine 24-Stunden-Wartezeit und eine biometrische Bestätigung. Der Weg ist bewusst reibungsintensiv gestaltet - laut Google, um Betrug bei Nötigungssituationen zu verhindern.

Warum das Lock-in ist, kein Sicherheits-Feature

Google rahmt den ganzen Schritt als Auflösung eines vermeintlichen Widerspruchs. Die Ankündigung beginnt mit dem Versprechen:

«You shouldn't have to choose between open and secure. By engineering security into the core part of the OS, Android has proven that you can have both, and we continue taking new steps in that direction. […] We've seen how malicious actors hide behind anonymity to harm users by impersonating developers […]. To better protect users […] we're adding another layer of security to make installing apps safer for everyone: developer verification.»

Rhetorisch ist das geschickt, sachlich ist es eine Verschiebung. «Offen» heisst auf Android bislang konkret: Man darf eine App installieren, ohne Google um Erlaubnis zu fragen. Genau diese Offenheit beschneidet die Verifizierungspflicht - der angebliche «Sowohl-als-auch»-Gewinn entsteht also gerade dadurch, dass die offene Seite stillschweigend kleiner wird. Wer Sicherheit wirklich «in den Kern des OS» baut, braucht dafür keine zentrale Entwicklerregistrierung; die beiden Dinge haben miteinander wenig zu tun.

Noch aufschlussreicher ist die zweite Wendung: Google erklärt Anonymität selbst zum Problem - «malicious actors hide behind anonymity» - und verkauft die Verifizierung als «another layer of security». Doch zu wissen, wer eine App veröffentlicht, sagt nichts darüber, ob ihr Code schädlich ist. Ein verifizierter Entwickler kann weiterhin Schadsoftware ausliefern; Ausweis und einmalige Gebühr sind für organisierte Betrüger eine kalkulierbare Hürde, kein Hindernis. Die Pflicht, sich mit echtem Namen und Ausweis zu registrieren, trifft dafür jene am härtesten, für die Anonymität kein Vorwand, sondern Schutz ist - Journalistinnen, Whistleblower, Entwickler in autoritären Staaten. Aus «accountability» wird so weniger ein Schutz vor Kriminellen als ein Register über alle, die legitim publizieren.

Google begründet den Schritt mit Sicherheit und verweist auf eigene Zahlen: Man habe über 50-mal mehr Schadsoftware aus sideloaded Quellen gefunden als im Play Store. Eine Quelle oder Methodik für diese Zahl nennt Google allerdings nicht - sie steht ohne Beleg im Raum. Die Pointe liegt aber in Googles eigener Analogie: Die Verifizierung sei wie ein «ID-Check am Flughafen, der die Identität bestätigt, aber getrennt ist von der Sicherheitskontrolle des Gepäcks». Genau das ist der Punkt. Ein Identitätsabgleich prüft, wer eine App veröffentlicht - nicht, ob ihr Code sicher ist. Das Scannen auf Schadsoftware übernimmt auf Android bereits Google Play Protect, unabhängig von der Entwickleridentität.

F-Droid, das seit Jahren freie Apps verteilt, formuliert es deutlich: «We do not believe that developer registration is motivated by security» - man halte es für einen Schritt, um Macht zu konsolidieren und die Kontrolle über ein zuvor offenes Ökosystem zu verfestigen. Die EFF geht weiter und beschreibt identitätsbasiertes Gatekeeping als Infrastruktur für Zensur: Wer ein Tor errichtet, lädt Behörden ein, es zu nutzen, um zu blockieren, was ihnen missfällt. Eine zentrale Datenbank mit den Klarnamen aller Entwickler ist ausserdem ein offensichtliches Ziel für Datenpannen und behördliche Herausgabeverlangen - ein reales Risiko für Entwickler, die anonym arbeiten müssen, etwa Journalistinnen oder Menschen in autoritären Staaten.

Aus der Lock-in-Perspektive ist die Mechanik entscheidend: Die Pflicht verlängert Googles Torwächter-Rolle über den eigenen Play Store hinaus in jeden Vertriebskanal. Ein konkurrierender Store kann noch so unabhängig sein - seine Entwickler müssen sich trotzdem bei Google registrieren, dessen Bedingungen akzeptieren und im Zweifel mit einem Entzug der Verifizierung rechnen. Das ist Marktkontrolle ohne formelles Verbot. Mehrere Entwicklerverbände haben Google deshalb in einem offenen Brief aufgefordert, das Vorhaben zurückzunehmen.

Was offen bleibt - und was nicht

Der Geltungsbereich ist die wichtigste Nuance. Die Pflicht greift nur auf zertifizierten Geräten. Entgoogelte Android-Varianten wie CalyxOS, GrapheneOS oder LineageOS verzichten bewusst auf die Google-Zertifizierung - und liegen damit ausserhalb dieses Gates. Auf einem solchen Gerät existiert der Verifier-Dienst gar nicht; Sideloading und alternative Stores funktionieren weiter wie bisher.

Für das offene Ökosystem ist die Lage damit nicht entwarnt. F-Droid signiert die verteilten Apps in der Regel mit dem eigenen Schlüssel; Googles Modell erwartet aber genau eine Entwicklersignatur - was das Verteilmodell von F-Droid auf zertifizierten Geräten grundsätzlich bricht. Die Freiheit, eine App ohne Googles Erlaubnis an ein beliebiges Standardgerät zu verteilen, verschwindet also real - sie überlebt nur dort, wo Nutzer aktiv ein nicht-zertifiziertes System wählen.

Ein neuer Grund für ein entgoogeltes Smartphone

Bisher war ein entgoogeltes Smartphone vor allem eine Datenschutz-Entscheidung: Man wollte nicht, dass Google jede Bewegung, jede App und jede Suche mitliest. Mit der Verifizierungspflicht kommt ein handfester, neuer Grund dazu - und es ist ein grosser. Es geht nicht mehr nur darum, wer Sie beim Nutzen Ihres Geräts beobachtet, sondern darum, wer entscheidet, was Sie auf Ihrem Gerät überhaupt installieren dürfen.

Auf einem zertifizierten Standardgerät trifft diese Entscheidung ab 2026 schrittweise Google. Auf einem entgoogelten System wie CalyxOS oder GrapheneOS bleibt sie bei Ihnen: Der Verifier-Dienst existiert dort gar nicht, Sideloading und alternative Stores wie F-Droid funktionieren weiter wie bisher. Wer also heute überlegt, dem Google-Ökosystem den Rücken zu kehren, hat ab 2026 nicht nur ein Datenschutz-Argument, sondern auch ein Freiheits-Argument: die Installationsfreiheit, die auf Standardgeräten verschwindet.

Der Einstieg ist niederschwelliger, als viele denken. Ein entgoogeltes Smartphone müssen Sie nicht selbst aufsetzen - Sie können es vorkonfiguriert beziehen oder sich bei der Auswahl des passenden Geräts und Systems beraten lassen. Im Alltag bleibt vieles vertraut; was sich ändert, ist, dass die Kontrolle über das Gerät wieder bei Ihnen liegt.

Wer Android in der eigenen Organisation strategisch einsetzt - interne Apps, Geräteflotte, eigene Produkte -, sollte die Abhängigkeit zusätzlich nüchtern prüfen:

1. Vertriebswege inventarisieren. Verteilen Sie interne Apps per APK oder MDM? Klären Sie früh, ob Ihre Entwickler die Verifizierung durchlaufen müssen und was das für anonyme oder ausgelagerte Entwicklung bedeutet.
2. Alternative Bezugsquellen testen. F-Droid und direkte APK-Installation bleiben auf nicht-zertifizierten Geräten nutzbar - ein Testgerät schafft Klarheit über den realen Funktionsumfang.
3. Geräte-Souveränität bewerten. Geräte ausserhalb des zertifizierten Google-Ökosystems behalten die Installationsfreiheit, die auf Standardgeräten ab 2026 schrittweise verschwindet - relevant überall dort, wo diese Unabhängigkeit geschäftskritisch ist.

Die Entwickler-Verifizierung ist kein technisches Detail, sondern eine Verschiebung darüber, wer entscheidet, welche Software auf einem Gerät laufen darf. Wer diese Entscheidung nicht vollständig an einen einzelnen Anbieter delegieren will, sollte die Weichen stellen, solange Wahlfreiheit noch besteht.