Google verbietet Sideloading von anonymen Apps ab Herbst 2026

[xflr-7]

@prx wird auch nicht passieren.....

 

[prx]

Ich bin bei Prognosen gerade etwas vorsichtig. Ist nicht die Zeit, länger als zwei Wochen in die Zukunft zu planen.

 

[Otandis_Isunos]

@bananensaft Der Android-Quellcode ist größtenteils unter der freizügigen Apache License 2.0 und nicht unter einer Copyleft-Lizenz lizenziert. Daher hat Google da eben nicht alles Recht der Welt da was zu ändern

Da wir eh schon auf Kriegsfuß stehen:

Google kann den Code von Android jederzeit verändern, weitergeben und nutzen und ihn, wenn Google danach ist, auch unter einer anderen Lizenz als der Apache Lizenz veröffentlichen. Warum das geht? Eben weils KEINE Copyleft-Lizenz ist, wo der Code unter der selben Lizenz veröffentlicht werden muss.

Apache ist eine Permissive-Lizenz.

Wenn Google danach ist, könnte es Android auch closed Source machen. Muss aber trotzdem die ursprünglichen Autoren anerkennen innerhalb des Projektes.

Beiträge automatisch zusammengeführt: 29.08.2025

Nachtrag: Okay nicht komplett Android. Den Linuxkernel nicht

 

[maik005]

Ich gebe zu, ich habe nicht alles gelesen.
Nur mal ein schneller Gedanke...
Was spricht dagegen sich als Privatperson "Als Entwickler" zu registrieren, wenn es nicht anders ginge, und dann z.b. Revanced Apps o.ä. selbst zu signieren mit dem eigenen persönlichen Schlüssel?

 

[Marvin42]

Richtig, machen sie auch.

und die werden dann auch ohne PlayProtect blockiert?

Ich denke, es wird weiterhin Wege geben, wie man Apps installieren kann die nicht unbedingt die Voraussetzung erfüllen, wie es in Artikel steht.

Ja, den Check Rauspatchen bzw. Custom ROM.
Aber dann kämpfst du mit Problemen wie dem Play Integrity Status.

Nachtrag: Okay nicht komplett Android. Den Linuxkernel nicht

Ja, und die GPL2 hat anders als ihr Nachfolger keine Anti-DRM Klausel.

Möglicherweise hat Google Fuchsia entwickelt um die GPL los zu werden.
Darum ist es allerdings sehr still geworden.

 

[swa00]

@maik005

Guter Ansatz, könnte man.
Stellt sich dann nur die Frage, welche arme Sau dann das Fett abbekommt und wie lange der neue Paketname noch auf der Whitelist wäre .

@Marvin42

im PlaySTore ohne PP, und auf dem Device mit PlayProtect , nannte sich früher Remote Application Removal , oder KillSwitch.
Auf dem Device kann das lt. mehreren Developer Berichten auch noch ohne aktiviertem PlayProtect wirken.
Das kann ich aber persönlich nicht verifizieren.

 

[Skyhigh]

@swa00

Ja der Paketname wird dann von der Whitelist entfernt, aber was spricht dagegen dem Kind einfach einen neuen Paketnamen zu verpassen?

Laut Google gibt es ja eben gerade keine Inhaltsprüfung der Apps (betrifft nur das sideloading, wenn man in den store will ist die Inhaltsprüfung natürlich Pflicht).
Man könnte also wieder und wieder und wieder die Inhaltstechnisch selbe App mit anderem Paketnamen und neuer Signatur in Umlauf bringen, oder?

Edit:
Ich beziehe das jetzt auf malware und Scam, nicht auf Hobbyentwicklung.

Evtl denke ich aber auch gerade verkehrt
Wird eigentlich beim Anruf einer API der Name des Pakets geloggt der drauf zugreift? So rein aus Interesse. Falls nein macht es das ganze ja noch schwieriger

 

[swa00]

@Skyhigh

Absolut richtig .....

Aber sei doch mal ehrlich: Wer wird für ein Produkt ständig den Paketnamen für den "Normalo" ändern und auch immer wieder eine andere juristische & haftbare Person dafür einsetzen, die den Kopf hinhält ?
(Die Identität erfolgt mit dem gleichem Aufwand , wie ein BankAccount)

Wie ich ja oben schon einmal erwähnte :
Du kannst es nicht absolut dicht machen , aber bei Weitem mehr eindämmen, als die bisherige WildWest Manie..

Und damit wird den Lizenzgebern schon sehr unter die Arme gegriffen ...

Kollege @bananensaft hat es schön auf den Punkt gebracht :

Man muss auch sagen, Google könnte das Sideloading auch komplett sperren. Und dann wär ganz Schicht im Schacht. Aber sie versuchen gerade alle Interessen unter einen Hut zu bringen, dass kann man durchaus auch würdigen.

Wird eigentlich beim Anruf einer API der Name des Pakets geloggt der drauf zugreift?

Könntest du das bitte spezifizieren ?
Meinst du damit einen https API Request, oder einen internen Aufruf einen Bibliotheks-API ?

Wenn Du die Bibliothek meinst : Ja
Denn i.d.R. wird kein statischer "Aufruf" durchgeführt, sondern das Paket bei der Bibliothek registriert und Daten angefordert.
Die Bibliothek liefert der App dann asynchron die Daten, wenn verfügbar .

Wenn Du den https Request meinst : Nein


Welchen Hintergrund verfolgst du mit dieser Frage ?

 

[Skyhigh]

@swa00 danke erstmal

Aber sei doch mal ehrlich: Wer wird für ein Produkt ständig den Paketnamen ändern und auch immer wieder eine andere juristische & haftbare Person dafür einsetzen, die den Kopf hinhält ?
(Die Identität erfolgt mit dem gleichem Aufwand , wie ein BankAccount)

Naja meine Gedanken gehen dabei vor allem an Leute mit krimineller Energie. Also die scammer, die jetzt schon großen Aufwand betreiben indem sie:
-Mehrere domains vorhalten
-Hunderte sipgate Nummern vorhalten
-sehr oft zur Registrierung solcher Dienste jetzt schon Identitätsdiebstahl begehen.

Und das nur, weil es sich für sie lohnt.
Ich kann mir nicht vorstellen, dass die sich davon unterkriegen lassen.

Und damit wird den Lizenzgebern schon sehr unter die Arme gegriffen ...

Und das ist ja auch gut.
Ich möchte wirklich nicht den Eindruck erwecken, dass ich diesen Gedanken schlecht finde!
Ich sehe nur immer noch nicht, wie das registrieren ohne Inhaltsprüfung da tatsächlich helfen soll.
Ja man bekommt eine ladungsfähige Anschrift, aber hilft das wirklich, wenn die Person die man dann belangen möchte überhaupt nichts davon weiß?

Ich hatte so einen Fall von Identitätsdiebstahl in meinem Bekanntenkreis das ist sehr unschön für den betroffenen und verursacht extreme kosten.
Daher verzeih mir bitte wenn ich da skeptisch bin.

Könntest du das bitte spezifizieren ?
Meint du damit einen https API Request, oder einen internen Aufruf einen Bibliotheks-API ?

Welchen Hintergrund verfolgst du mit dieser Frage ?

Ich meinte jetzt unter anderem dein Beispiel mit eurer Freemium API oder der YouTube API in Kombination mit dem Einwand von @maik005 , dass man ja die YT-Mod auch selbst signieren könnte.
Wenn es dazu nun ein Tool wie den Vanced Patcher gäbe, und das wird es wahrscheinlich irgendwann geben, bei dem man seine eigene Signatur angeben müsste, würde das demnach auffallen.

Aber rechtlich dagegen vorzugehen würde bei der Flut an "neuen Apps" Jahre dauern nehme ich an.
Das würde sicherlich das Rechtssystem überladen.

Ich habe keine Interesse daran irgendwelche API zu missbrauchen, keine Sorge. Ich hatte nur in Gedanken die Situation weiter gespielt.
War aus meinem post nicht wirklich hervorgegangen, sorry dafür.

 

[xflr-7]

@Skyhigh zumal du gar nicht alle wirklich rechtlich dranbekommen würdest. Google wird sich durch derartige Aktionen nur selbst ins Bein schießen. Die Leute die langsam das grübeln anfangen werden immer mehr. Wie gesagt es wird auch bei Google diskutiert und die die denken das das für die Entwickler passiert haben es eh nicht gerafft Google tut nichts für die Entwickler. Selbst die eigenen Google Entwickler, Sicherheitsteams usw haben sich für AOSP stark gemacht... Wurden von der Geschäftsabteilung mundtot gemacht.... Hier geht es um andere Dinge und insbesondere die kleinen deutschen Entwickler interessieren keine Sau....

 

[Skyhigh]

@xflr-7 leider ist das in den letzten Jahren vermehrt der Fall, das Einschränkungen und Systemlocks quer durch die TechIndustrie im "Namen der Sicherheit" durchgeboxt werden. Das betrifft nicht nur Smartphones.

Im Grunde bin ich ja überhaupt nicht davon abgeneigt die Sicherheit zu erhöhen.
Auch habe ich überhaupt kein Problem damit, Dienste und Anbieter zu entlohnen, wenn ich ihre Arbeit nutzen möchte und sie mir auch wirklich im Alltag hilft, die Devs müssen auch von was leben.

Was mir dabei aufstößt ist, dass die ganzen Einschnitte immer mehr die Möglichkeiten einschränken.
Wenn mir Möglichkeiten genommen werden etwas selbst zu tun ist das zum kotzen.
Sei es am Auto, Smartphone, NAS System, oder einfach nur bei einem einfachen Alltagsding.
Ich muss zugeben das versaut mir immer mehr den Spaß an meinen Technik Hobbys und DAS stört mich gewaltig.

 

[swa00]

@Skyhigh

Ich möchte wirklich nicht den Eindruck erwecken, dass ich diesen Gedanken schlecht finde!

Kam nicht ansatzweise so rüber - erst recht nicht bei Dir

Google wird nicht da eine Armanda von Server installieren, die tag-täglich schauen, ob es etwas Auffälliges gibt
- das ist so auch eigentlich nicht möglich.
Google stellt lediglich jetzt ein Werkzeug zur Verfügung - anwenden muss es der - nennen wir es mal "Geschädigte"


Mit dem Konzept wird nun dem Lizenzbetreiber die Kontrolle in die Hand gegeben - dieser Mechanismus fehlt bis heute gänzlich.
Fällt ihm etwas auf, hat er nun die Möglichkeit den Entwickler direkt zu kontaktieren, oder - falls erfolglos - Google mit ins Boot nehmen und die Sperrung des Paketes zu Veranlassen.

-Mehrere domains vorhalten
-Hunderte sipgate Nummern vorhalten
-sehr oft zur Registrierung solcher Dienste jetzt schon Identitätsdiebstahl begehen.

Ich vermute ich stehe damit jetzt auf dem Schlauch .
Was sollen domains/spigate mit einem Content-Request eines Pakets zu tun haben ?

Natürlich wird es so Dinge wie identitätsdiebstahl geben, das steht ausser frage, aber wie oben schon erwähnt:
Im Zweifelsfalle wird erst mal das Paket gesperrt .

Im Übrigen ein geläufiges Vorgehen von Google :
Erst wird (oft ohne Grund) gesperrt, erst dann wird der Entwickler angeschrieben.
Apple tut das anders herum und räumt Karenzzeiten ein.

Ich meinte jetzt unter anderem dein Beispiel mit eurer Freemium API oder der YouTube API in Kombination mit dem Einwand von @maik005 , dass man ja die YT-Mod auch selbst signieren könnte.

Was nutzt dir derzeit das gleiche Paket mit einer anderen Signierung auf einem zertifizierten Gerät ?

 

[Skyhigh]

Ich vermute ich stehe damit jetzt auf dem Schlauch .
Was sollen domains/spigate mit einem Content-Request eines Pakets zu tun haben ?

Das hatte mit dem Content-Request nichts zu tun
Das war auf andere Kriminelle Machenschaften (überwiegend TelefonScam aus z.B Indien, welcher sich auch häuft) bezogen, bei denen häufig die falschen Personen belangt werden, weil falsche Angaben zur Person gemacht werden.

Ich hab gedanklich die Registrierung des Pakets bei Google mit der Registrierung anderer Dienste gleich gezogen.

Was nutzt dir ein Paket mit einer anderen Signierung auf einem zertifizierten Gerät ?

Ich glaube da reden wir aneinander vorbei.

Wenn ich durch einen Patcher den Paketnamen ändere und den neuen Namen registrieren lasse, diesen mit der Signatur der Registrierung signiere, dann ist dass ohne Inhaltsprüfung ja erstmal technisch möglich, wenn ich das nicht falsch verstanden habe (möglicherweise habe ich das ja bisher auch).

Ich weiß, dass man so einfach nicht durchkommen würde, dennoch als vereinfachtes Beispiel:

com.google.android.youtube
->com.skyhigh.android.youtube -> signieren mit meiner Signatur
->com.swa00.android.youtube -> signieren mit deiner Signatur
->com.maik005.android.youtube -> signieren mit seiner Signatur
->usw

Dann wären das doch technisch gesehen erstmal eigenständige Apps, da Google laut eigenen Aussagen bei der Signierung fürs Sideloading keine Inhaltsprüfung durchführt.
Diese somit gepatchten Apps würden sich per Sideloading installieren lassen und erstmal funktionieren wie jede andere illegal gepatchte App vor der Sperre auch. sehe ich das Richtig?

Wenn das nun jeder Forennutzer machen würde, wäre das ja eine riesen Flut mit einem, auf die Masse gesehen, enormen Aufwand für Youtube. Jedoch bleibt der Aufwand - pro Enduser - relativ "gering" im vergleich da es einen Patcher wie z.B aktuell den VancedPatcher gibt.

Das schafft sicherlich Arbeitsplätze in Sachen Sperrung bei Google, oder Google übernimmt den Apple weg. Wir werden sehen.

 

[swa00]

sehe ich das Richtig?

Absolut richtig - nicht umsonst übergibt Google die Verantwortung/Anwendung an den Lizenzgeber.
Wenn dieser sich nicht darum kümmert (oder muss) - bleibt alles beim Alten.

Das schafft sicherlich Arbeitsplätze in Sachen Sperrung bei Google, oder Google übernimmt den Apple weg.

Das könnte man erst genauer beantworten, wenn das Portal steht - Lt. meinen Informationen wird das in den nächsten Wochen freigeschaltet - dann wissen wir auch mehr.


Wie das im Falle YT intern bei Google umgesetzt wird, vermag ich nicht zu beurteilen -

Ich könnte mit durchaus vorstellen , das die da schon etwas in der Schublade liegen haben ( Device basierend)
Eine Idee aus der Hüfte : YT Request nur durch ein bestimmtes Paket.
(Recht einfach durch einen AES Token Header zu bewerkstelligen)


Kleine Anmerkung :
Das Ganze wird m.E. viel zu heiss gekocht und die "Beschränkung" die du persönlich anführst , ist ja keine richtige Beschränkung für dich.
Du kannst nachwievor deine LieblingsApp installieren, solange der Entwickler bereit ist , seine Arbeit zu zertifizieren.
Wenn er das nicht tut, hat er seine Gründe, warum auch immer ....

Ein Punkt, der für einen (registrierten) Hobbyprogrammierer allerdings relevant ist, ist dass er in Zukunft direkt in die Haftung genommen werden kann ...... Das ist aber nicht ein Part von Google, sondern vom Gesetzgeber.

Und ja, das ist unbestritten - so manche gute Projekte werden dadurch nur noch als OpenSoucre zum selbskomplieren zur Verfügung gestellt.

 

[xflr-7]

Das Portal wird ab September freigeschaltet und die Entwickler können sich dann anmelden. In Deutschland frühstens 2027. Google muss abchecken ob die EU das durchlässt daher zuerst in Indonesien usw

"Melden Sie sich jetzt für den frühen Zugang an

Hier ist der Zeitplan, der Ihnen bei der Planung hilft:

Oktober 2025: Der frühe Zugang beginnt. Die Einladungen werden nach und nach verschickt.

März 2026: Die Verifizierung wird für alle Entwickler geöffnet.

September 2026: Diese Anforderungen treten in Brasilien, Indonesien, Singapur und Thailand in Kraft. Zu diesem Zeitpunkt müssen alle Apps, die auf einem zertifizierten Android-Gerät in diesen Regionen installiert sind, von einem verifizierten Entwickler registriert werden.

2027 und darüber hinaus: Wir werden diese Anforderungen weiterhin weltweit einführen."

 

[Marvin42]

Ein Punkt, der für einen (registrierten) Hobbyprogrammierer allerdings relevant ist, ist dass er in Zukunft direkt in die Haftung genommen werden kann ...... Das ist aber nicht ein Part von Google, sondern vom Gesetzgeber.

Anonym Software zu erstellen ist gesetzlich verboten?

 

[xflr-7]

@Marvin42 nein natürlich nicht und Google wird es für Europa lange nicht unsetzen. Also erst mal locker bleiben

 

[swa00]

@Marvin42

App Entwickler haften gesetzlich für Ihr Produkt.
Bis dato war es allerdings schwierig an anonyme Entwickler bei Bedarf diesbezüglich heran zu kommen.

Dies wird nun umgesetzt.

 

[xflr-7]

Da wird in den nächsten 3 Jahren gar nichts umgesetzt. Wie kann man denn so stumpf immer wieder das gleiche falsch behaupten. Ich hab doch oben aus den Infos die die Entwickler von Google bekommen haben/werden zitiert. Da ist der Zeitplan ganz deutlich hinterlegt.

 

[swa00]

@xflr-7

a) Du hast in Post 135 zum xten Male wiederholt, was bereits in der ersten Seite offiziell bestätigt worden ist.

Und das stammt von mir selbst und kommt aus dem internen Entwicklerbereich Post#8
Du brauchst also nicht zu korrigieren


b) Und dein letzter Post hat genau so viel Nährwert, dass du eigentlich gemerkt haben müsstest, dass man dich schon längst ignoriert.

Mit anderen Worten : Lass es besser bleiben.