Fakestore, blankstore, gms, microg, unifiednlp – was ist das Beste für Android ohne Gapps?

Ich verwende Android seit vielleicht 2 Jahren ohne Gapps oder ein Google-Konto und mag die Erfahrung, aber ich würde es auch gerne besser machen, weil einige Apps, die ich früher verwendet habe, jetzt nicht ohne einige Google-Dienste laufen. Ich habe NoGapps recherchiert, verstehe aber die Informationen und die verschiedenen verfügbaren Pakete nicht gut genug, um zu wissen, was ich brauche.

Es sieht so aus, als ob dies Pakete sind, die den Google Play Store und die APIs der Hauptdienste simulieren, aber entweder Nulldaten, minimale Antworten oder Daten von anderen Open-Source-Anbietern zurückgeben? Aber ich kann keine klare Erklärung finden, welche Optionen es gibt und welche Hauptunterschiede zwischen ihnen bestehen, um mir bei der Auswahl der zu installierenden Optionen zu helfen.

Mein aktuelles Telefon ist Lineage 14.1 + SuperSU 2.79 auf einem Samsung S7 G930F, und ich verwende den Play Store nicht (ich verwende FDroid und Sideloading).

Aktualisieren

Nur zur Verdeutlichung (nach @Izzys hervorragender "Grundlagen" -Antwort bisher): Das Hauptproblem, wenn man darüber nachdenkt, ist nicht so sehr "welches dieser Pakete kann ich verwenden, um eine Google-Bibliothek zu ersetzen".

Das eigentliche Problem ist, inwieweit diese No-Gapps-Alternativen das mutmaßliche Ziel erreichen, Software weiterhin funktionieren zu lassen (indem sie einen Playstore/Standortanbieter/anderen Dienst vortäuschen, von dem sie erwarten, dass GApps bereitgestellt haben), aber in Wirklichkeit auch bereinigen oder vermeiden Google dafür tatsächlich zu verwenden oder zu reduzieren und klarzustellen, welche Daten an Google gesendet werden, wenn sie verwendet werden.

So sendet beispielsweise Fakestore nichts an Google, Punkt, seine Aufgabe ist es vorzutäuschen, dass der Google Play Store installiert ist und seine Android-API funktioniert, aber leider nicht erreichbar/leer ist. Aber für den Rest ist es wirklich schwer zu wissen, was noch gesendet wird und was bereinigt oder nicht gesendet wird. Wenn alles, was es gibt, eine FOSS-Neuimplementierung einer Google-Bibliothek ist, dieselben Daten, dieselbe Authentifizierung, größtenteils dieselbe Protokollierung/Datenerfassung, ist das ein bisschen schwach und unglücklich, auch wenn es unvermeidlich ist. Wenn Nlp Google vollständig vermeiden und vertrauenswürdigere Quellen verwenden kann, ist das besser. Aber das ist die Art von Informationen und Diskussionen, über die ich keine Details finden kann.

Ich bin hier realistisch - eine Person, die eine App haben möchte, die Google Push-Benachrichtigungen benötigt, muss diese Funktionalität entweder als installiert, aber nicht reaktionsfähig vortäuschen oder Code verwenden, der die Daten bereinigt und Datenlecks so gut wie möglich vermeidet, oder sie akzeptieren kann diese App nicht verwenden. Aber die Informationen, die für diese Entscheidung benötigt werden, sind Klarheit darüber, was diese NoGapps-Software tun kann, um Datenlecks zu minimieren oder zu vermeiden, und wie weit sie gehen können, um sich von Google zu unterscheiden.

Das ist ziemlich zentral für "warum ich sie verwenden möchte". Ich würde gerne klarer machen, was ihre Kompromisse sind und was möglich ist oder nicht, in Bezug auf Daten und Informationen, die an Google weitergegeben werden, und das bin ich nicht, was mich daran hindert, sie an Geldautomaten zu genießen.

Antworten (1)

Einige Grundlagen zuerst:

  • NoGAPPS ist veraltet und wurde durch seinen Nachfolger µG (sprich: microG) ersetzt.
  • µG umfasst den Kern (im Grunde GServices) und auch UnifiedNlp.
  • Kein GService-Ersatz unterstützt die Google License API. Das ist eine viel zu heiße Gegend. Obwohl wir alle Zahnärzte lieben, sehen wir sie besser nicht an uns arbeiten (ersetzen Sie in diesem Zusammenhang „Zahnärzte“ durch „Anwälte“).
  • Es gibt jedoch Möglichkeiten, auf den PlayStore zuzugreifen, und Sie haben einige Kandidaten erwähnt:
    • BlankStore: Veraltet, außer Bugfixes nicht mehr gepflegt, aber Nachfolger noch nicht fertig. Unterstützt nur kostenlose Apps.
    • FakeStore: Wie der Name schon sagt, nur ein „Fake“ – dh es täuscht die Anwesenheit von Playstore für Apps vor, die sonst nicht funktionieren.
    • Yalp: Wie BlankStore, aber weiterhin gepflegt, plus unterstützende Apps, die Sie bereits gekauft haben (aber nicht den Kaufprozess und nicht die Lizenzprüfung, die einige kostenpflichtige Apps durchführen).
    • Weitere Kandidaten in meiner entsprechenden App-Liste .

Ich verwende diese Kombination (CyanogenMod + µG mit UnifiedNlp + BlankStore/Yalp) jetzt seit ungefähr 2 Jahren. Das einzige, was ich als nicht funktionierend empfunden habe, waren kostenpflichtige Apps, die ihre Lizenz gegen GPlay verifizieren wollten – ansonsten läuft alles reibungslos. Einzelheiten finden Sie in meiner Artikelserie zu Android ohne Google . Beachten Sie jedoch, dass es derzeit einige Probleme mit LOS 14.x und UnifiedNlp zu geben scheint; Details finden Sie im Issue Tracker auf der Github-Präsenz von µG.

Den Stand der Umsetzung finden Sie im Wiki des Projekts, sowie eine kurze Einführung . In Bezug auf den Datenschutz können Sie aus diesen beiden ableiten:

Als Ersatz für die Closed-Source-Google Apps (GAPPS) ist es ein leistungsstarkes Tool , um Ihre Privatsphäre zurückzugewinnen und gleichzeitig die Android-Kernfunktionen zu genießen.

(aus der Einleitung; Hervorhebung von mir). Sehen Sie sich im Implementierungsstatus zwei Spalten genauer an: Funktionalität und Absturz. Wenn beide "Nein" sind, haben wir einen Dummy: Apps denken, es ist da, aber es passiert rein gar nichts (insbesondere keine Datenübertragung); dies ist und bleibt zum Beispiel für Analytics und Ads der Fall. Keine Funktionalität und Abstürze bedeutet, dass nichts implementiert ist (nicht einmal ein Dummy) – daher können Apps, die darauf zugreifen, abstürzen, aber auch hier wird nichts übertragen (derzeit z. B. Auto und Cast).

Sofern Daten übermittelt werden, beschränkt sich dies nach meiner Kenntnis auf das für die zu erreichende Funktionalität unbedingt notwendige Minimum. Dazu gehören z. B. Google Cloud Messaging (Token, ID und natürlich die Nachricht müssen ausgetauscht werden, wobei letztere normalerweise nur eingehend ist), Kontoauthentifizierung (raten Sie mal: Kontoname und Token/Passwort müssen dafür gesendet werden, oder es kann nicht eine Authentifizierung sein), Maps API (muss natürlich die gewünschte Position für die abzurufenden Kacheln senden – die geht aber nicht an Google, da es stattdessen OpenStreetMap/OpenScienceMap verwendet). Fused Locations läuft auch nicht über Google, sondern nutzt stattdessen die UnifiedNlp-Backends.

Das sind wirklich hilfreiche Grundlagen, danke. Wenn ich darüber nachdenke, was mir nicht klar ist (und wichtig ist), ist, wie viel jedes dieser nur als FOSS dieselben Google-API-Aufrufe neu implementiert (und daher immer noch dieselben grundlegenden Probleme nur über eine andere Middleware aufwirft) oder ein Google benötigt Login usw.) und wie sehr sie Sie von Google trennen. Ich bin realistisch, wenn Sie Google-Benachrichtigungen/E-Mail/Suche/Sprache/Kalender wünschen, ist es realistisch, dass Google es unterwegs dataminen wird. Aber für die meisten von ihnen gibt es keine klaren Informationen darüber, was von Google getrennt wurde und was an sie weitergeleitet wird, was sehr hilfreich wäre
Siehe mein Update, hoffe es ist jetzt klar. Apropos "löschen": Ich werde die jetzt überflüssigen Kommentare löschen, die ich bereits in die Antwort integriert habe :)
Danke - das ist wirklich klar! Eine letzte Frage (optional) - gibt es irgendwo eine Liste mit genau den Daten und/oder Tracking-Funktionen, die für jede Google-Bibliotheksfunktion unvermeidlich sind, um ein Gefühl dafür zu bekommen: "Die Verwendung von Feature/API X ist nicht möglich, es sei denn, man lässt Google haben Daten Y; Sie können die Tokens jedoch randomisieren oder sie jedes Mal für mindestens Daten Z" löschen ? Das wäre sehr schön, aber wenn es existiert, kann ich es nicht finden
Ich bin mir dessen nicht bewusst und gehe eher "aus dem Bauch heraus" damit um (z. B. mit Xprivacy, zufällige Dinge wie Standort, Geräte-IDs usw.). Aber welche Daten genau in welchem ​​Zusammenhang gesendet werden, entzieht sich meiner Kenntnis. Wenn Sie das wirklich untersuchen wollen, müssen Sie leider die Netzwerkpakete "schnüffeln" - es sei denn, jemand hat genau das bereits getan, und Sie können die Ergebnisse aufdecken. Obwohl sich selbst das mit neuen Versionen der Dienste/Apps ändern könnte…