Angekündigt ist nicht gestartet: Googles Android-Register bleibt Mitte August lückenhaft

Google will Android sicherer machen und zugleich offen halten. Das ist der Anspruch. Der überprüfbare Zwischenstand ist unbequemer: Der regionale Durchsetzungsrahmen für die Entwicklerverifizierung ist inzwischen ziemlich konkret. Der für August angekündigte öffentliche Zugang zu wichtigen Ausnahmen und Werkzeugen ist am 16. August dagegen nicht vollständig belegt.

Das klingt zunächst nach einer gewöhnlichen Verzögerung in einer Produkteinführung. Tatsächlich berührt es die zentrale Machtfrage des neuen Systems: Wer darf künftig Software auf zertifizierten Android-Geräten normal verteilen – der Eigentümer des Geräts, das App-Projekt, ein alternativer Store oder Google als Betreiber des Registers?

Bereits am 4. August erschienen bei Darknight-Coffee Podcast und Blog zur grundsätzlichen Kontrollarchitektur. Dieser Text ist kein Doppelartikel, sondern ein datiertes Update. Zwei Dinge haben sich präzisiert: Eine offizielle Hilfeseite nennt jetzt ausdrücklich zertifizierte Geräte ab Android 8. Gleichzeitig bleibt ein pauschaler „August-Start ist erfolgt“ zu stark.

Der September-Rahmen ist belegt

Google nennt den 30. September 2026 als Beginn der Durchsetzung in Brasilien, Indonesien, Singapur und Thailand. Sieben beteiligte Stores werden aufgeführt: Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Palm Store, vivo V-Appstore und Xiaomi GetApps. Die weltweite Ausweitung ist für 2027 und danach angekündigt.

Die offizielle Android-Hilfe ordnet die Initiative zertifizierten Android-Geräten ab Android 8 zu. Auf betroffenen Geräten arbeitet laut Google der Systemdienst com.google.android.verifier. Er soll prüfen, ob eine App einem registrierten Entwickler zugeordnet ist.

Das ist mehr als eine Regel für den Play Store. Die Registrierung verbindet Entwickleridentität, Paketname und normale Installierbarkeit. Nicht registrierte Apps sollen zwar nicht absolut uninstallierbar werden. Google nennt ADB und den Advanced Flow als Ausnahmen. Der Normalweg wird trotzdem neu geordnet: registriert und regulär auf der einen Seite, nicht registriert und nur über einen Sonderweg auf der anderen.

Wer daraus „F-Droid wird am 30. September weltweit abgeschaltet“ macht, überzieht. Die erste Durchsetzung betrifft vier Länder, sieben beteiligte Stores und zertifizierte Geräte. Der konkrete Effekt auf Installationen und Updates muss auf realen Geräten geprüft werden. Wer dagegen behauptet, es handle sich nur um eine interne Play-Store-Regel, verharmlost die Reichweite.

Der August-Start ist nicht vollständig nachgewiesen

Google hatte am 15. Juli drei Bausteine für August angekündigt: Limited-Distribution-Konten, den Android Developer Console API und den Advanced Flow zum Installieren nicht registrierter Apps.

Für Limited Distribution beschreibt die Dokumentation bereits den geplanten Ablauf. Das kostenlose Konto soll Apps an höchstens zwanzig ausdrücklich autorisierte Geräte verteilen können. Ein QR-Code oder Link stellt den Kontakt her, der Nutzer stimmt am Gerät zu, anschließend erfolgt die Registrierung über die Android Developer Console.

Doch die offizielle Limited-Distribution-Seite erklärte beim Abruf am 16. August weiterhin, die Anmeldung zum Early Access sei geschlossen. Zugang erhalte nur eine kleine Gruppe; weitere Informationen sollten im August folgen. Das ist kein Beleg für einen allgemeinen öffentlichen Start. Es ist ein Beleg für vorhandene Dokumentation bei weiterhin begrenztem Zugang.

Ähnlich vorsichtig muss die Console API behandelt werden. Google beschreibt, wie Paketnamen und Schlüssel aus Entwicklungsumgebungen oder CI/CD verwaltet werden sollen. Eine Status-API soll Paketnamen und Berechtigung prüfen. OAuth-Delegation soll alternativen Stores erlauben, Vorgänge im Auftrag eines Entwicklers auszuführen. Eine frei zugängliche API-Referenz, ein eindeutiger General-Availability-Vermerk und ein praktischer Test mit berechtigtem Konto wurden in der zugrunde liegenden Recherche jedoch nicht gefunden beziehungsweise nicht durchgeführt.

Die richtige Formulierung lautet daher: Google hat Funktionen und Zeitplan weitgehend beschrieben. Ein vollständiger öffentlicher Start aller August-Bausteine ist am 16. August nicht belegt.

Zwanzig Geräte lösen kein F-Droid-Problem

Das kostenlose Hobbykonto ist eine echte Ausnahme. Es verzichtet nach Googles Beschreibung auf Gebühr und amtlichen Ausweis. Für eine Lerngruppe, eine Familie oder einen kleinen Testkreis kann das nützlich sein.

Es ist aber kein Ersatz für freie öffentliche Verteilung. Eine Matrix-Community mit achtzehn Moderatoren, zwei Ersatztelefonen und einem neuen Helfer überschreitet die Grenze bereits. Ein öffentliches F-Droid-Repository kennt seine künftigen Nutzer nicht einzeln und kann sie nicht vorab auf eine Gästeliste setzen. Eine Community-App für Backup-Status, Token-Widerruf oder .well-known-Prüfungen wird nicht unsicherer, nur weil ein einundzwanzigstes Gerät sie benötigt.

Die Grenze zeigt, welches Modell Google normalisiert: Der Entwickler verwaltet autorisierte Empfänger in einer zentralen Infrastruktur. Freie Verteilung funktioniert anders. Das Projekt stellt Quellcode, Buildinformationen, Signatur und Paket bereit; Nutzer entscheiden selbst, ob sie diesem Vertriebsweg vertrauen.

Eigene Bewertung: Limited Distribution ist besser als ein vollständiger Ausschluss kleiner Entwickler. Als Antwort auf die Kritik an der Plattformmacht reicht sie nicht. Zwanzig genehmigte Geräte sind ein Testkreis, keine offene Infrastruktur.

Der Advanced Flow ist Schutz und Abstufung zugleich

Google beschreibt für erfahrene Nutzer einen einmaligen Freischaltweg: Entwicklermodus aktivieren, bestätigen, dass keine telefonische oder andere Anleitung durch Dritte erfolgt, Gerät neu starten, erneut authentifizieren, einen Tag warten und die Ausnahme anschließend für sieben Tage oder unbefristet aktivieren.

Die Schutzlogik ist plausibel. Scam-Coaching lebt von Zeitdruck und Fernanleitung. Neustart und Wartefrist können einen laufenden Betrugsversuch unterbrechen. Wer das leugnet, stellt eine politische Zuspitzung über die technische Realität.

Die andere Hälfte der Realität lautet: Dieselbe Hürde trifft bewusst gewählte freie Software aus einer bekannten Quelle. Der Ablauf unterscheidet nicht zuerst zwischen einer APK aus einem anonymen Chat und dem dokumentierten Build einer Community. Er unterscheidet nach Registerstatus. Damit wird unabhängige Software vom normalen Eigentümerentscheid zum besonders behandelten Ausnahmefall.

Eigene Bewertung: Warnungen, Signaturhinweise und Schutz vor erkennbarer Fernsteuerung sind richtig. Eine pauschale Hürde aus Entwicklermodus, Neustart und Wartefrist macht den Konzernregistereintrag aber zum Privileg des bequemen Weges. Freiheit bleibt formal erhalten und wird praktisch herabgestuft.

Paketnamen sind die eigentliche Machtstelle

Für Google Play hat Google Regeln zur Registrierung von Paketnamen veröffentlicht. Der Schlüssel mit mehr als fünfzig Prozent der bekannten Installationen soll priorisiert werden. Ohne Mehrheitsinhaber können Schlüssel mit mindestens fünfzig Installationen berechtigt sein. Unterhalb der Schwelle gilt zunächst „first come, first served“; weitere Schlüssel benötigen einen Antrag.

Für freie Software ist das keine bloße Verwaltungsfrage. Reguläre F-Droid-Pakete werden häufig aus geprüftem Quellcode neu gebaut und mit einem F-Droid-Schlüssel signiert. Bei reproduzierbaren Builds kann F-Droid den eigenen Nachbau mit einer upstream-signierten APK vergleichen und anschließend das Original verteilen. Nicht jede App und Version ist jedoch reproduzierbar.

Damit können Upstream, F-Droid und weitere Repositories technisch legitime, aber unterschiedlich signierte Pakete derselben freien Software anbieten. Ein zentrales Register muss entscheiden, welcher Schlüssel welchem Paketnamen zugeordnet wird. F-Droid erklärt, es könne Entwickler weder zur Google-Registrierung zwingen noch deren Paketnamen stellvertretend beanspruchen.

F-Droids Warnung, das System könne den Store „wie wir ihn heute kennen“ beenden, ist eine Interessenposition des betroffenen Projekts. Sie ist keine eingetretene Tatsache. Die strukturelle Kollision ist trotzdem real: Ein dezentrales Build- und Vertriebsmodell trifft auf eine zentrale Namens- und Identitätsordnung.

Identität ist keine Codeprüfung

Googles stärkstes Gegenargument darf nicht unterschlagen werden. Wiederkehrende Betrüger können unter wechselnden Namen Apps verbreiten. Eine überprüfte Identität erhöht ihre Kosten. Smartphones werden außerdem von Menschen genutzt, die keine APK-Signaturen oder Buildketten beurteilen können.

Eine Identität beantwortet aber nur einen Teil der Sicherheitsfrage. Sie beweist nicht, dass das Binärpaket aus dem veröffentlichten Quellcode entstand. Sie verhindert keine kompromittierte Bibliothek und kein übernommenes Entwicklerkonto. Auch F-Droids Modell garantiert keinen fehlerfreien Code und keinen reproduzierbaren Build für jede App. Sicherheit braucht mehrere Ebenen: Signaturen, nachvollziehbare Builds, transparente Berechtigungen, schnelle Updates, verständliche Warnungen und belastbare Verantwortlichkeiten.

Eigene Bewertung: Google verbindet eine sinnvolle Rechenschaftsfunktion mit einer Infrastruktur für Marktzugang. Das kann Betrug erschweren und zugleich Abhängigkeit erzeugen. Der erste Effekt macht den zweiten nicht unsichtbar.

Was Betreiber jetzt tun sollten

Freie Projekte und Communities müssen nicht in Panik geraten. Sie sollten ihren Bestand erfassen:

Welche Paketnamen werden verteilt?
Wer kontrolliert die Signaturschlüssel?
Welche APKs stammen vom Upstream, welche aus F-Droid oder eigenem Build?
Welche Geräte sind zertifiziert und laufen mit Android 8 oder neuer?
Reicht ein Rahmen von zwanzig Geräten einschließlich Ersatz- und Testgeräten wirklich aus?

Ein Update- und Restore-Test auf einem Ersatzgerät ist wertvoller als zehn Vermutungen. Prüfsummen, Schlüssel-Fingerprints und Verantwortlichkeiten gehören in die Betriebsdokumentation. Für interne Apps braucht es einen Rückweg, falls Registrierung, API oder Store nicht erreichbar sind.

Vor allem braucht es sprachliche Disziplin. Bis ein allgemeiner Zugang, eine eindeutige API-Freigabe oder reale Feldtests vorliegen, müssen offene Punkte offen bleiben. Kritik an Plattformmacht wird nicht schwächer, wenn sie Unsicherheit benennt. Sie wird glaubwürdiger.

Fazit

Der September-Termin ist real. Die Geräteklasse ab Android 8 ist jetzt offiziell benannt. Die geplante Verknüpfung von Entwickleridentität, Paketname und normaler Installierbarkeit ist keine Erfindung von Kritikern.

Ebenso real ist die Lücke im August: Die öffentliche Limited-Distribution-Seite zeigt weiterhin geschlossenen Early Access. Die Console API ist beschrieben, aber ihre allgemeine Produktivverfügbarkeit nicht eindeutig belegt. Deshalb darf eine Ankündigung nicht als vollzogener Start verkauft werden.

Google verbietet freie Android-Software nicht vollständig. Google macht die eigene Registrierung jedoch zum Normalweg und verschiebt freie Verteilung in einen Ausnahmeweg. Das ist die belegbare Linie – ohne Panik, aber auch ohne Weichspüler.

Eigene Schlussbewertung: Ein Smartphone gehört seinem Käufer nur dann praktisch, wenn dieser einen unabhängigen, verständlichen und dauerhaften Weg zur Installation signierter Software besitzt. Sicherheit darf diesen Weg mit Informationen schützen. Sie darf ihn nicht in eine widerrufliche Konzern-Ausnahme verwandeln.