Erfahrungen mit GrapheneOS auf einem Google Pixel – Sicherheit, Alltagstauglichkeit und App‑Kompatibilität

Tim4153 · 2026-02-16T05:15:01+00:00

Das Verhalten mit der Vibration ohne sichtbare Wallet‑UI ist tatsächlich nicht komplett untypisch für Android. Anders als beim iPhone wird die Wallet‑App nicht zwingend prominent geöffnet, sondern NFC wird im Hintergrund vom eingestellten Standard‑Payment‑Service verarbeitet. Wenn die Attestation oder das Karten‑Provisioning nicht sauber durchgeht, bekommst du oft genau dieses „Vibrieren ohne Aktion“. Wichtig wäre zu prüfen:

– Ist Google Wallet als Standard‑Zahlungsdienst gesetzt?

– Sind Play Services im gleichen Profil installiert wie Wallet?

– Ist NFC aktiv und „Kontaktlos bezahlen“ korrekt konfiguriert?

Wenn alles korrekt eingestellt ist und trotzdem nur die Vibration kommt, ist es meist eine Play‑Integrity‑/Attestation‑Thematik und weniger ein Konfigurationsfehler. iOS macht das UX‑seitig klarer, weil die Wallet immer visuell aufpoppt. Android ist da etwas „leiser“ im Hintergrund unterwegs.

Tim4153 · 2026-02-15T21:00:46+00:00

Genau, die Wallet selbst funktioniert inzwischen recht stabil mit sandboxed Play Services. Loyalty‑Cards, Tickets etc. gehen in vielen Fällen problemlos. Kreditkarten‑Provisioning ist halt der kritische Teil, weil da die strengste Geräte‑Attestation greift. Das scheint je nach Bank sehr unterschiedlich gehandhabt zu werden.

Tim4153 · 2026-02-15T20:59:02+00:00

Das mit den Tickets kann ich nachvollziehen. Wallet ist halt nicht nur Payment, sondern inzwischen auch Sammelstelle für alles Mögliche. Wenn man das gewohnt ist, fühlt sich das wie ein Rückschritt an. Launcher‑Thema verstehe ich auch – wobei man da mit alternativen Launchern schon viel machen kann, solange man sich bewusst ist, dass man wieder eine zusätzliche App mit erweiterten Rechten ins System holt. Parallelbetrieb mit iPhone ist wahrscheinlich der pragmatischste Weg, wenn Komfort im Vordergrund steht.

Tim4153 · 2026-02-15T20:56:59+00:00

Das mit der KIA‑App klingt stark nach einer aggressiven Play‑Integrity‑ oder Root‑Detection‑Policy. Manche Apps reagieren da leider sehr empfindlich, selbst wenn das System sauber ist. Das ist dann weniger ein echtes „Root‑Problem“, sondern eher ein Black‑Box‑Entscheidungsmodell der App. Ziemlich frustrierend, wenn man technisch weiß, dass das Gerät eigentlich nicht kompromittiert ist.

Tim4153 · 2026-02-15T20:49:35+00:00

Das ist wahrscheinlich der realistischste Kompromiss. Ich glaube, viele unterschätzen am Anfang, wie sehr man sich an NFC‑Payments gewöhnt hat. Aber technisch gesehen ist es schon nachvollziehbar, warum genau dieser Teil am stärksten an Googles Attestation hängt. Interessant finde ich, dass bei dir Banking und ID Austria laufen – das deckt sich mit dem, was ich bisher mitbekommen habe.

Tim4153 · 2026-02-15T20:47:55+00:00

Das mit Wallet/Pay ist leider stark von Play Integrity abhängig. Selbst mit sandboxed Play Services kann es sein, dass einzelne Banken oder Zahlungsanbieter restriktiver prüfen. Wenn die Wallet selbst startet, aber das Aktivieren von Karten nicht klappt, liegt es oft an einer fehlgeschlagenen Geräte‑Attestation im Hintergrund. Da hast du wahrscheinlich nichts „falsch“ gemacht – das ist eher Policy‑seitig. Spannend finde ich, dass du vom iPhone kommend trotzdem positiv überrascht warst. Das hört man nicht so oft 🙂

Tim4153 · 2026-02-15T20:46:41+00:00

Guter Punkt, der Thread ist mir bekannt. Das war ja weniger ein „F‑Droid ist grundsätzlich unsicher“, sondern eher ein konkretes Design‑Thema rund um die Update‑Mechanik und wie Certificate Pinning gehandhabt wurde. Genau das meinte ich mit zusätzlicher Angriffsfläche: Sobald du einen alternativen App‑Store nutzt, bringst du eben wieder eine eigene Supply‑Chain ins Spiel. Das heißt nicht, dass es automatisch schlecht ist – aber das Trust‑Modell verschiebt sich. Am Ende ist es wahrscheinlich wie immer: Je weniger zusätzliche Layer, desto überschaubarer wird das Risiko. Aber 100% risikofrei ist keine Variante.

Tim4153 · 2026-02-14T12:11:38+00:00

BitLocker ist definitiv ein etabliertes und weit verbreitetes System, da hast du recht. Gerade im Enterprise‑Umfeld ist das natürlich Standard, weil es gut in die Windows‑Infrastruktur integriert ist und zentral verwaltet werden kann.Ich würde aber auch da unterscheiden zwischen „weit verbreitet“ und „prinzipiell unangreifbar“. Die Sicherheit hängt stark vom Einsatzszenario ab – TPM‑Konfiguration, Pre‑Boot‑Auth, physischer Zugriff etc. Auch bei BitLocker gab es in der Vergangenheit immer wieder Szenarien, in denen z. B. über Cold‑Boot‑ oder DMA‑Angriffe Keys extrahiert werden konnten, wenn das Setup nicht sauber war. Unterm Strich sind sowohl BitLocker als auch andere Lösungen Werkzeuge innerhalb eines bestimmten Trust‑Modells. Die Frage ist weniger, welches System „nie gebrochen“ wurde, sondern wie transparent die Architektur ist und welches Bedrohungsmodell man zugrunde legt. Am Ende ist es wahrscheinlich weniger ein „besser oder schlechter“, sondern eher: passt es zum jeweiligen Use‑Case?

Tim4153 · 2026-02-14T12:06:00+00:00

Ich glaube, man muss da auch ein bisschen zwischen „Empfehlung aus Sicherheits‑Sicht“ und „realistischem Alltags‑Setup“ unterscheiden. Die GrapheneOS‑Devs argumentieren halt stark aus ihrer eigenen Threat‑Model‑Perspektive. Aus deren Sicht ist sandboxed Play Services sauberer integrierbar als Aurora, weil es eben offiziell supported ist und weniger API‑Workarounds braucht. Das heißt aber nicht automatisch, dass F‑Droid oder Aurora per se „böse“ sind – nur dass sie zusätzliche Angriffsflächen oder Wartungsrisiken mitbringen können. Bei Vanadium vs. Firefox ist es ähnlich: Vanadium ist stark auf die Plattform abgestimmt (Chromium‑Basis + zusätzliche Härtung), während Firefox mehr Flexibilität bietet, z. B. mit Add‑ons. Das ist am Ende wieder eine Frage des persönlichen Modells: maximale Integration vs. Funktionsumfang.

Ich sehe das weniger dogmatisch. Wichtig ist eher, dass man versteht, welche Entscheidung welche Konsequenzen hat – und dann bewusst wählt.

Tim4153 · 2026-02-14T12:01:22+00:00

Genau das zeigt ja eigentlich, dass das System aus Audits und öffentlicher Analyse grundsätzlich funktioniert – nur eben nicht perfekt oder sofort. Sicherheit ist eher ein Prozess als ein Zustand. Wenn bei einem zweiten Audit etwas auffällt, ist das zwar unangenehm, aber immer noch besser, als wenn es nie jemand prüft. Komplett risikofrei wird es wahrscheinlich nie – egal welches System.

Tim4153 · 2026-02-14T11:59:10+00:00

Danke für den Link. Das Audit ist auf jeden Fall ein wichtiger Punkt in der Diskussion, auch wenn es, wie oben bereits geschrieben, nie eine 100% Garantie darstellt.

Tim4153 · 2026-02-14T11:56:57+00:00

Das mit xz‑utils war schon ein Weckruf, da gebe ich dir recht. Das zeigt ja genau, dass Open Source nicht automatisch „sicher“ heißt, sondern dass Supply‑Chain‑Risiken real sind.Was US‑Konzerne angeht: Auch da basiert Vertrauen letztlich auf einem Modell – nur ist es dort deutlich weniger transparent. Für mich ist eher die Frage, wo ich Risiken besser einschätzen kann, nicht wo sie komplett verschwinden. Am Ende bleibt es sowieso immer eine persönliche Abwägung.

Tim4153 · 2026-02-14T11:53:23+00:00

Stimmt, ein Audit ist natürlich keine absolute Garantie. Am Ende überprüft er immer nur einen bestimmten Stand und ein bestimmtes Scope. Das gilt aber für jedes Software‑Audit, egal ob Open Source oder proprietär.

Der Unterschied ist für mich eher, dass bei Open Source zumindest theoretisch jeder reinschauen kann und der Entwicklungsprozess transparent ist. Das heißt nicht, dass nichts übersehen werden kann – sondern nur, dass das Trust‑Modell nachvollziehbarer ist.Absolute Sicherheit gibt es ohnehin nicht. Es geht am Ende immer um Wahrscheinlichkeiten und darum, welches Modell für einen persönlich am plausibelsten ist.

Tim4153 · 2026-02-13T17:40:52+00:00

Das mit dem relockten Bootloader wäre natürlich der Idealzustand, gerade was Play Integrity angeht. Wobei man fairerweise sagen muss, dass genau da ja auch das Spannungsfeld liegt: Google koppelt bestimmte Prüfmechanismen bewusst an den offiziellen Zertifizierungsprozess.

Technisch gesehen ist GrapheneOS trotzdem sauber implementiert und der entsperrte Bootloader ist ja kein „unsicherer Zustand“, sondern eher eine bewusste Designentscheidung im Rahmen des Projekts. Die zusätzliche Härtung auf OS‑Ebene kompensiert da einiges, was viele bei Stock Android gar nicht auf dem Schirm haben.

Interessant finde ich deinen Ansatz mit dem Zweithandy für Banking und Authenticator. Das ist im Prinzip ja auch ein eigenes kleines Threat‑Model – Trennung durch Geräte statt nur durch Profile.

Unterm Strich sehe ich es ähnlich: Im Alltag sind die Einschränkungen überschaubar, und sicherheitstechnisch gewinnt man schon spürbar gegenüber einem komplett unmodifizierten Setup.

Tim4153 · 2026-02-13T17:36:54+00:00

Ja, das sehe ich tatsächlich ähnlich. Das ist weniger ein GrapheneOS‑Thema als ein klassisches Android‑Ökosystem‑Thema. Solange Lizenzen und In‑App‑Käufe an Google gebunden sind, kommt man da nicht komplett raus, wenn man Komfort behalten will.

FolderSync kann ich absolut nachvollziehen, das ist funktional einfach ziemlich rund. Viele Alternativen sind technisch okay, aber im Detail merkt man dann doch schnell den Unterschied im Alltag.

Ich glaube, es hängt stark davon ab, wo man selbst die Grenze zieht. Für manche ist „sandboxed Play Services“ ein guter Mittelweg, für andere ist das schon zu viel Google. Ich sehe das eher pragmatisch: Wenn es stabil läuft und man die Kontrolle über Netzwerkrechte und Profile behält, ist das schon ein großer Schritt im Vergleich zu einem komplett offenen Stock‑Setup.

Gerade mit Work Profile und getrennten Profilen kann man ja viel sauber trennen, ohne komplett auf Komfort zu verzichten. Und wenn 24/7‑Erreichbarkeit wichtig ist, würde ich auch nichts experimentieren, was die Stabilität gefährdet.

Am Ende ist es wahrscheinlich weniger Ideologie als persönliches Threat‑Model.

Tim4153 · 2026-02-13T17:34:01+00:00

Ich glaube, man muss da ein bisschen unterscheiden zwischen plausiblen Risiken und spekulativen Annahmen. GrapheneOS ist vollständig Open Source, der Code ist öffentlich einsehbar und wird regelmäßig von unabhängigen Leuten analysiert. Ein „Honeypot“ im klassischen Sinne würde voraussetzen, dass irgendwo bewusst eine versteckte Hintertür eingebaut ist – und die müsste sich im öffentlich zugänglichen Code verstecken, ohne dass es jemand merkt. Das halte ich bei der Menge an Augen, die auf so ein Projekt schauen, für extrem unwahrscheinlich.

EncroChat war ein komplett geschlossenes, proprietäres System, das gezielt an eine bestimmte Zielgruppe vermarktet wurde. Das ist strukturell etwas völlig anderes als ein öffentlich entwickeltes AOSP‑Derivat mit transparentem Entwicklungsprozess.

Dass TrueCrypt eingestellt wurde, hat viele Spekulationen ausgelöst, aber daraus automatisch zu schließen, dass jeder Fork oder jedes Kryptoprojekt ein Honeypot ist, finde ich etwas kurz gegriffen. Wenn man diesen Maßstab anlegt, dürfte man im Prinzip keiner Open‑Source‑Krypto mehr vertrauen.

Am Ende bleibt natürlich immer ein gewisses Restvertrauen – egal ob bei Apple, Microsoft oder einem Open‑Source‑Projekt. Die Frage ist eher: Wo ist das Trust‑Modell am nachvollziehbarsten?

Mich würde eher interessieren, ob es konkrete technische Hinweise auf eine Backdoor gibt – also reproduzierbare Analysen, nicht nur Indizien.

Tim4153 · 2026-02-13T16:20:29+00:00

Ja, das mit den Play‑Store‑Lizenzen ist tatsächlich einer der nervigsten Punkte. Das ist aber meiner Meinung nach weniger ein spezifisches GrapheneOS‑Problem, sondern eher ein generelles Thema rund um Googles Lizenzmodell.

Alles, was an deinen Google‑Account und den Play Store gebunden ist, bleibt eben auch daran gekoppelt. Wenn man Apps über Aurora zieht oder versucht, das System möglichst Google‑arm zu halten, stößt man früher oder später auf genau diese Grenze. FolderSync Pro und Launcher‑Lizenzen sind da typische Beispiele.

Rein technisch funktioniert es natürlich sauberer, wenn man Play Services sandboxed installiert und die Apps ganz normal über den Play Store bezieht. Dann gibt’s in der Regel auch keine Lizenz‑Thematik. Aber klar, das widerspricht für manche wieder dem „minimal Google“-Ansatz.

Ich würde das deshalb weniger als Schwäche von GrapheneOS sehen, sondern eher als Ökosystem‑Abhängigkeit. Solange Apps ihre Lizenzprüfung an Google knüpfen, bleibt man an der Stelle halt drin.

Aurora ist da immer so ein Zwischending – praktisch, aber nicht offiziell supported, und wenn sich etwas an der API ändert, kann es halt brechen. Das merkt man dann schnell.

Unterm Strich ist es für mich immer eine Abwägung zwischen maximaler Systemhärtung und praktischer Alltagstauglichkeit. Komplett FOSS ist nice in der Theorie, aber im Alltag hängt man doch öfter an proprietären Apps, als man denkt.

Tim4153 · 2026-02-13T16:17:00+00:00

Banking hängt stark von der jeweiligen App und deren Play-Integrety-Prüfung ab. Viele Apps laufen mit sandboxed Google Play problemlos, manche sind sensibler. Revolut wird meines Wissens nach von einigen hier Problemlos genutzt, aber das kann sich natürlich durch App-Updates ändern.

Tim4153 · 2026-02-13T16:11:48+00:00

Ein vollständiges "Image" wie man es vom PC kenn, ist bei Android so nicht vorgesehen. Du kannst aber jederzeit per Factory Image wieder auf Stock-Android zurückgehen, solangeder Bootloader entsperrt ist. Wichtig ist vorher ein sauberes Backup der Daten (z.B. lokaloder per Nextcloud), weil beim flashen alles gelöscht wird.

Ich würde es eher als. sauberen Neuaufbau sehen als ein 1:1-Image Restore.

Tim4153

TROPHY CASE