https://www.kuketz-blog.de/android-entwickler-verifizierung-weniger-offenheit-mehr-kontrolle/

Mike Kuketz
19. September 2025
Android: Entwickler-Verifizierung – weniger Offenheit, mehr Kontrolle
1. Entwickler-VerifizierungAndroid-Entwickler-Verifikation

Google führt eine Entwickler-Verifizierung für Android ein. Ab 2026 sollen auf zertifizierten Android-Geräten nur noch Apps installiert werden, die einem verifizierten Entwicklerkonto zugeordnet sind – gleichgültig, ob die App aus dem Play Store kommt, aus einem Dritt-Store stammt oder als APK direkt installiert wird. Die Durchsetzung startet in ausgewählten Ländern (Brasilien, Indonesien, Singapur und Thailand) und wird anschließend ausgeweitet. Installationen über ADB sind weiterhin möglich und nicht an die Verifizierung gebunden. Für normale Nutzer ist das jedoch keine alltagstaugliche Option.

Im Folgenden beleuchten wir, was diese Änderung konkret bedeutet – sowohl für Entwickler, die ihre Apps künftig nur noch mit Verifizierung auf zertifizierten Geräten anbieten können, als auch für Nutzer, deren Spielraum bei der Installation freier Apps eingeschränkt wird.
2. Was ändert sich konkret?

Google verlangt künftig, dass Entwickler ihre Identität nachweisen und ihre Apps (Paketnamen und ggf. Signierschlüssel) einem verifizierten Konto zuordnen. Dafür gibt es zwei Wege: Wer bereits die Play Console nutzt, kann darüber auch Apps registrieren, die außerhalb des Play Store verteilt werden. Für Entwickler, die nur jenseits des Play Store veröffentlichen, richtet Google eine eigene Android Developer Console (ADC) ein (Early Access ab Okt. 2025, allgemein ab März 2026).

Abgefragt werden unter anderem Name, Anschrift, E-Mail und Telefonnummer. Bei Organisationen zusätzlich eine Website sowie eine D-U-N-S-Nummer – eine neunstellige Kennziffer, die von der Firma Dun & Bradstreet vergeben wird und weltweit als eindeutige Identifikation von Unternehmen dient (auch Apple verlangt sie für Entwicklerkonten von Organisationen). Diese Pflicht betrifft nicht nur US-Firmen, sondern ebenso Entwickler aus Deutschland oder anderen europäischen Ländern, etwa GmbHs, UGs oder eingetragene Vereine. Teils ist auch ein amtlicher Ausweis erforderlich. Laut Google werden diese Daten nicht gegenüber Nutzern angezeigt. Für Hobby- und Studierenden-Entwickler soll es ein vereinfachtes Konto ohne Registrierungsgebühr geben.

Google begründet die Pflicht mit mehr Sicherheit und Nachverfolgbarkeit. In der Praxis entsteht damit jedoch eine zusätzliche Hürde – insbesondere für kleine, nebenberufliche oder anonyme FOSS-Projekte. Wer nicht verifiziert ist, scheitert künftig auf zertifizierten Geräten an einer Systemblockade: Android prüft beim Installieren ob die App von einem verifizierten Entwicklerkonto stammt und mit dem passenden Schlüssel signiert wurde. Fehlt die Verifizierung, blockiert das System – egal ob die App über F-Droid, einen anderen Store oder direkt von der Projektseite kommt.

Nach aktuellem Stand gilt die Pflicht nur für zertifizierte Android-Geräte – also solche mit Play Protect und vorinstallierten Google-Apps. Custom-ROMs wie GrapheneOS sind nicht zertifiziert und damit formal nicht betroffen. Für die große Mehrheit der Nutzer ändert das jedoch nichts: Sie verwenden zertifizierte Geräte – und genau dort wird die Installation freier Apps künftig erschwert.
3. Und was ist mit F-Droid und anderen App-Stores?

F-Droid baut die meisten Apps selbst aus dem Quellcode und signiert sie mit dem eigenen Reposchlüssel. Daneben gibt es den Mechanismus der reproduzierbaren Builds: Dabei erstellt F-Droid ein APK aus dem Quellcode und vergleicht es mit der vom Entwickler veröffentlichten Version. Sind beide Dateien bytegenau identisch – abgesehen von der Signatur –, kann F-Droid statt eines eigenen Builds auch das Original-APK mit der Signatur des Entwicklers ausliefern. Das Verfahren ist aufwendig und gelingt noch nicht bei jeder App, wird aber zunehmend genutzt, um mehr Transparenz und Vertrauen in die Builds zu schaffen.

Mit der Entwickler-Verifizierung rückt auf zertifizierten Geräten künftig jedoch vor allem eine Frage in den Vordergrund: Wer signiert – und ist dieser Signierer bei Google verifiziert? Daraus ergeben sich aus meiner Sicht zwei Szenarien:

Wenn der ursprüngliche Entwickler signiert und verifiziert ist: Der Entwickler veröffentlicht das APK mit seinem eigenen Schlüssel und hat sein Konto bei Google verifiziert. F-Droid kann dieses Original-APK ausliefern. Auf zertifizierten Geräten lässt sich die App installieren, weil die Signatur einem verifizierten Konto zugeordnet ist.
Wenn F-Droid selbst signiert: F-Droid baut die App und versieht sie mit dem eigenen Schlüssel. Damit diese APKs künftig auf zertifizierten Geräten akzeptiert werden, müsste sich F-Droid als Organisation bei Google verifizieren und die Paketnamen registrieren. Ohne diese Verifizierung blockiert das System die Installation. Das würde zusätzlichen organisatorischen Aufwand, mehr Verantwortung und Haftungsfragen nach sich ziehen – aktuell erscheint dieses Modell wenig realistisch.

Ein offizielles Statement von F-Droid zu Googles Plänen gibt es bislang nicht. In der Community wird das Thema diskutiert, doch konkrete Zusagen – etwa ob sich F-Droid selbst verifizieren will oder ob Prozesse angepasst werden – liegen bisher nicht vor.

F-Droid und andere App-Stores können ihre Repositories zwar weiterhin betreiben. Ob eine App auf zertifizierten Geräten installiert werden darf, hängt künftig jedoch nicht mehr vom Store ab, sondern allein davon, wer sie signiert hat – und ob dieser Signierer bei Google verifiziert ist. Das kann entweder der ursprüngliche Entwickler sein oder, falls F-Droid selbst signiert, F-Droid als Organisation. Auf nicht zertifizierten ROMs wie GrapheneOS greift diese Schranke nicht.
4. Custom-ROMs: Was gilt?

Die neue Pflicht greift nur auf zertifizierten Android-Geräten mit Play Protect und vorinstallierten Google-Apps. Custom-ROMs sind in der Regel nicht zertifiziert – damit fällt die Sperre dort formal nicht an. Das betrifft bspw. GrapheneOS, LineageOS, CalyxOS, oder /e/OS. Auch wenn man nachträglich GApps oder microG installiert, wird das ROM dadurch nicht plötzlich Play-Protect-zertifiziert. Apps aus F-Droid lassen sich weiter wie gewohnt installieren.

Wichtig ist die Einordnung: Auch wenn Custom-ROM-Nutzer vorerst unbeeinträchtigt sind, verschiebt sich das Gleichgewicht im gesamten Ökosystem. Die große Mehrheit nutzt zertifizierte Geräte – dort entscheidet künftig die Verifizierung des Signierers. Das kann dazu führen, dass sich Entwicklerressourcen stärker auf verifizierte Kanäle konzentrieren. Für Custom-ROM-Nutzer ändert sich kurzfristig wenig – langfristig hängt vieles davon ab, wie sich F-Droid, Projekte und Maintainer auf die neuen Rahmenbedingungen einstellen.
5. Sicherheit oder Kontrolle?

Google verkauft die neue Pflicht als »Sicherheitsmaßnahme«. Tatsächlich ändert sich an der technischen Prüfung nichts – Play Protect scannt schon heute alle Apps, egal woher sie kommen. Neu ist allein, dass ein Entwicklerkonto mit einer überprüften Identität verknüpft sein muss.

Damit entscheidet künftig nicht mehr die Qualität des Codes darüber, ob eine App installiert werden kann, sondern allein die Verifizierung des Entwicklers durch Google. Fehlt sie, blockiert das System die Installation – selbst wenn die App frei, quelloffen und technisch einwandfrei ist.

Das schafft Risiken: Ein gesperrtes Konto oder ein fehlerhaft zugeordneter Paketname kann ausreichen, um Updates zu verhindern. Anonyme oder kleine FOSS-Projekte, die keine Organisation gründen oder ihre Identität nicht preisgeben wollen, stoßen auf eine fast unüberwindbare Barriere. Die offene Verteilung wird damit faktisch eingeschränkt.

Kurz gesagt: Das Sicherheitsargument wirkt vorgeschoben. In Wirklichkeit vergrößert Google seinen Kontrollhebel und verschiebt die Norm – App-Installationen außerhalb des Play Store werden nicht mehr als regulär behandelt, sondern als Ausnahme unter Vorbehalt.

6. Was lässt sich jetzt tun?

Kurzfristig geht es vor allem darum, Apps aus möglichst nachvollziehbaren Quellen zu installieren – etwa direkt von der offiziellen Projektseite oder aus dem F-Droid-Hauptrepo. Wer bisher schon vorsichtig war und keine APKs aus dubiosen Download-Portalen nutzt, muss seine Gewohnheiten nicht grundlegend ändern. Wichtig ist lediglich, im Blick zu behalten, ob eine App plötzlich nicht mehr aktualisiert werden kann. Tritt dieser Fall ein, könnte die fehlende Entwickler-Verifizierung der Grund sein. Dann lohnt es sich, nach Hinweisen im Projekt oder bei F-Droid zu schauen, wie es weitergeht.

Mittelfristig braucht es stärkere Unterstützung für Projekte wie F-Droid. Das kann durch Spenden geschehen, durch Mithilfe bei Übersetzungen oder durch Beteiligung an Diskussionen in den Foren. Auch Entwickler profitieren, wenn ihnen Vorlagen und Werkzeuge zur Verfügung stehen, die den Veröffentlichungsprozess vereinfachen und reproduzierbare Builds erleichtern. Ebenso wichtig ist eine bessere Aufklärung für Nutzer: Schritt-für-Schritt-Anleitungen, die in verständlicher Sprache erklären, wie freie Apps auf zertifizierten Geräten installiert werden können und welche Einschränkungen zu erwarten sind, helfen mehr als technische Detailhinweise.

Langfristig wird entscheidend sein, Abhängigkeiten von Google zu verringern. Für manche bedeutet das den Umstieg auf Android-Varianten ohne Google-Zertifizierung wie bspw. GrapheneOS. Darüber hinaus braucht es politische Leitplanken: Wenn Google Verifizierungszwang mit dem (Schein-)Argument Sicherheit einführt, müssen Kriterien, Widerspruchswege und Transparenz rechtlich abgesichert werden. Nur so lässt sich verhindern, dass die Maßnahme als Vorwand genutzt wird, um unliebsame Software auszusperren. Stärken sollte man außerdem Projekte, die reproduzierbare Builds anbieten, da sie Vertrauen schaffen – unabhängig davon, ob Google sie akzeptiert oder nicht.

Test version.

Commit Message:

feat: add retry for voice transcription and better inline translation

See commit details 25f9110

https://rethinkdns.com/configure

Search for blocklists

https://github.com/mikropsoft/StevenBlock

🚫 Advanced Ad-Blocking Module for Android | Compatible with Magisk, KernelSU, and APatch 🔒

No deleted account found from 87 scanned users from this group 🚫👻

Invidious Service Unavailable 🤔🤷‍♂️

Host you're own Invidious at home

https://docs.invidious.io/installation/

https://youtu.be/JiB1tjPn-ZI?si=CcZmMj4yAg7bsCYq

Gsi rom network not working fix

### 1. What is verifiedBootKey

* This is the public key used to sign the boot image (boot/recovery/system, etc.).
* It is stored in the firmware and acts as the root of trust when verifying system integrity.
* The device manufacturer “burns” it into the Trusted Execution Environment (TEE) or processor fuses (eFuse/OTP).
* If the key doesn’t match the expected one, the system considers the boot process unsafe.

In simple terms:
verifiedBootKey = who signed the firmware (root of trust).

---

### 2. What is verifiedBootHash (or boothash)

* This is a hash (SHA256, etc.) of the boot partition contents (or a set of partitions, depending on AVB).
* It is calculated at boot time and compared with the reference value from the manifest.
* If the hash is different → the partition has been modified (e.g., custom kernel or ramdisk).

In simple terms:
verifiedBootHash = what exactly was loaded (the actual boot state).

---

### 3. Connection and difference

* BootKey determines whether we trust *the signer of the firmware*.
* BootHash determines whether *the boot partition itself has been modified*.

Analogy:

* Key (verifiedBootKey) = the manufacturer’s official stamp.
* Hash (verifiedBootHash) = the fingerprint of the specific paper that has the stamp.

---

### 4. In the context of Key Attestation

In Android Key Attestation the TEE signs a report that contains:

* verifiedBootKey — shows which key the device trusts.
* verifiedBootHash — shows what was actually loaded.
* Together they allow external services to verify that the device is booting in a trusted and unmodified environment.

DJI’s new sub-250g drone brings a massive upgrade – the DJI Mini 5 Pro has a 1” sensor

https://ift.tt/ZWciFlq