Bromite: WebView Stub apk zur Vereinfachung der Installation

Ich verstehe, was du meinst, aber ich könnte das nicht entwickeln. Sie könnten damit beginnen, so etwas zu entwickeln und zu sehen, wie es ist, es zu pflegen.

Alles, was mit SystemWebView zu tun hat, erfordert eine ständige Benutzerunterstützung.

Ich könnte einen Proof of Concept erstellen und testen. Aber am Ende müsste es offiziell signiert werden, um die Installation offizieller Builds von Bromite SystemWebView als Updates zu ermöglichen.

Außerdem könnte ein Überblick über die Fähigkeiten, die für die WebView erforderlich sind, abgesehen von den in ihrem Manifest deklarierten Berechtigungen und der Registrierung als System-Webview, gut sein, damit die Stub-APK nicht versehentlich alles vom System anfordern kann.

Eine andere Idee, die ich hatte, war, jedes Webview-Objekt zu füllen, das eine andere App mit dem Stub-APK erstellen könnte, würde mit nützlichen Informationen gefüllt. IE, wenn nur die Stub-APK installiert ist, würde das Öffnen meines Webview-basierten Browsers ihn mit dem Hinweis füllen, dass Bromite WebView noch nicht vollständig installiert ist und nur für die Funktion aktualisiert werden muss. Da ich mit den Interna einer Android-Webansicht völlig unbekannt bin, habe ich keine Ahnung, wie man dies erreicht.

Was die Wartung angeht, denke ich, dass es sogar unnötig sein könnte, die APK dafür mehr als einmal zu veröffentlichen. Solange sich Paketname und Signatur nicht ändern, sollte die Stub-Apk nicht geändert werden müssen. (und solange es keine Änderungen an Berechtigungen oder Privilegien gibt, die nur in der ursprünglichen APK-Datei deklariert werden können - aber ich bezweifle, dass diese in Android überhaupt existieren)

Okay, ich habe es gerade geschafft, eine super einfache Proof-of-Concept-Arbeit zu erhalten, indem ich einfach Folgendes getan habe:

• Erstellen Sie ein neues Android Studio-Projekt ohne eine Aktivität aus der Vorlage
• Entfernen Sie generierte App-Symbole, Designs und die Abhängigkeiten aus dem Gradle-Skript
• Baue & signiere das Ding
• Laden Sie einen offiziellen Build des Bromite System WebView herunter und kündigen Sie diesen mit demselben Schlüssel
• Platzieren Sie die Stub-Apk in /system/app/webview/ auf einem Android Pie-Gerät und starten Sie neu
  Zu diesem Zeitpunkt war in den Entwicklungseinstellungen kein Webview-Anbieter aufgeführt, aber die Installation des zurückgetretenen Bromite-Webview-Builds war erfolgreich und danach erschien Bromite System WebView in der WebView-Liste in den Entwicklungseinstellungen und die Verwendung von Webviews war möglich.

Nun sollte darauf geachtet werden, dass hier nichts übersehen wird und das Konzept auch ab Android 10 anwendbar ist (The Overlay Story). Aber abgesehen davon, dass es einmal funktioniert, sehe ich hier wirklich keinen zu erwartenden Wartungsaufwand.

Kopie des Quellcodes, den ich für meinen Test-APK-Stub verwendet habe:
https://github.com/SebiderSushi/WebViewStub-ProofOfConcept
(Aber die einzigen Dinge, die ich bisher als kritisch identifiziert habe, sind der Paketname und die Signatur.)

Okay, ich habe dies gerade auf einem Gerät mit Lineage 17.1 getestet und es hat auch funktioniert.
Was ich getan habe, war, den Magisk Installer von @linuxandria so zu
Das Installationsprogramm kümmert sich um das Overlay-Problem mit Android 10+.

Alles in allem lief es genauso gut wie beim Pie-Gerät - der Stub tauchte nicht in der WevView-Anbieterliste auf, aber sobald eine neu signierte komplette WebView-apk installiert wurde, tauchte er in der Liste auf und konnte sein von Anwendungen verwendet.

Nun sollte darauf geachtet werden, dass hier nichts übersehen wird und das Konzept auch ab Android 10 anwendbar ist (The Overlay Story).

Es könnte auf mehreren Android-Versionen mit Android Virtual Devices getestet werden.

Aber die einzigen Dinge, die ich bisher als kritisch identifiziert habe, sind der Paketname und die Signatur.

Dies ermöglicht es tatsächlich, ein anderes Paket mit demselben Namen und derselben Signatur zu installieren. Der Versionscode des Stubs sollte ebenfalls kleiner sein.

@SebiderSushi bezüglich des Paketnamens: Wir könnten auch einen Bromit-spezifischen Paketnamen verwenden, ich bin mir jedoch nicht sicher, ob dies dabei kaputt gehen würde. Wenn wir Benutzer mit einem entsperrten Bootloader ausschließen, der so ziemlich jeden Paketnamen verwenden kann, was sind die verbleibenden Anwendungsfälle, in denen es von Vorteil ist, com.android.webview (wie es derzeit ist) beizubehalten? Wissen Sie, was andere Webview-Entwickler dagegen tun?

Siehe auch: https://github.com/bromite/bromite/wiki/Installing-SystemWebView#about -the-package-name

Es tut mir leid, dass ich dieses Problem so lange in die Länge gezogen habe.
Ich habe kürzlich bemerkt, dass ich kein Setup (Gerät, Stock-ROM, Custom-ROM) besitze, bei dem es bei der Installation des Bromite WebView zu Komplikationen kommt. Das heißt, es ist mir aufgefallen, dass ich Bromite WebView als Benutzer-App auf allen meinen Setups installieren und verwenden konnte, indem ich einfach die vorinstallierte com.android.webview APK-Datei aus dem System-Image entfernte.
("alle Setups" impliziert alles, was zunächst com.android.weview als Webview-Anbieter auf die Whitelist setzt)

Ich konnte dies auch in einem AVD mit Android Pie reproduzieren.

Im Grunde habe ich also festgestellt, dass ich keinen Anwendungsfall dafür besitze und auch keine Testressourcen bereitstellen kann, die einer kritischen Situation ähneln, in der eine Installation auf der Systempartition obligatorisch wäre.

Ansonsten, um auf deine Frage zurückzukommen:
Aufgrund der Tatsache, dass System WebView-Anbieter explizit im System-Framework auf die Whitelist gesetzt werden müssen, wäre die Wahl eines Bromit-spezifischen Paketnamens für jeden nützlich, der in der Lage ist, sein System-Framework so zu patchen, dass dieser Name auf die Whitelist gesetzt wird. Abgesehen davon würde es meistens nur Anwendungsfälle unterstützen, in denen die Systemversion von com.android.webview installiert bleiben soll.

Die Sache mit dem Paketnamen com.android.webview ist, dass es viele ROMs gibt, die diesen Paketnamen als Webview-Anbieter auflisten, OHNE dass er auch mit einem speziellen Schlüssel signiert werden muss, wie es bei Google Chrome oder ähnlichen Dingen der Fall ist. Deshalb ist die Verwendung dieses Paketnamens auch für Leute mit entsperrten Bootloadern am einfachsten.
Aber so wie es jetzt aussieht (mit AVB und so) ist es meistens unmöglich, eine benutzerdefinierte WebView-Implementierung ohne einen entsperrten Bootloader und Dinge wie Magisk- oder Systempartitionszugriff zu verwenden, da normalerweise bereits ein Paket für alle im System vorinstalliert ist Whitelist-System WebView-Anbieter.

IIRC Ich habe vielleicht gesehen, dass com.google.android.webview ohne Signatur-Pinning in einem bestimmten Stock-ROM auf die weiße Liste gesetzt wurde, aber ich kann mir nicht vorstellen, wie Google auf die Verwendung ihres Paketnamens reagieren könnte.

Bromite einen eindeutigen Paketnamen zu geben, wäre technisch richtig, funktioniert aber leider nur, wenn Benutzer ihre Framework-res.apk patchen können oder wenn das WebView vom ROM-Maintainer oder -Entwickler gebündelt wird.

IIRC Ich habe vielleicht gesehen, dass com.google.android.webview ohne Signatur-Pinning in einem bestimmten Stock-ROM

Es hat keinen Vorteil, com.android.webview mit com.google.android.webview zu tauschen, aber überall, wo Sie sie ohne Signatur-Pining sehen, handelt es sich um einen ernsthaften Sicherheitsfehler.
Sie würden sich nicht darum kümmern, da die Authentizität durch die Signatur garantiert wird, nicht durch den Paketnamen (siehe das Zitat in https://github.com/bromite/bromite/wiki/Installing-SystemWebView#installation-ohne-root), sondern als Ich sagte, dass es keinen Anreiz gibt, einen anderen Paketnamen zu verwenden, da es nur bei Installationen mit "Backdoor" funktioniert. Und wenn Sie manuell eine Hintertür hinzufügen, können Sie auch einfach einen Bromite-spezifischen Paketnamen mit der richtigen Signatur hinzufügen.

Bromite einen eindeutigen Paketnamen zu geben, wäre technisch richtig, funktioniert aber leider nur, wenn Benutzer ihre Framework-res.apk patchen können oder wenn das WebView vom ROM-Maintainer oder -Entwickler gebündelt wird.

Wenn für einen SystemWebView-Installationsvorgang root erforderlich wäre, könnten wir einfach einen Bromite-spezifischen Paketnamen verwenden. Die Wiki-Seite erwähnt den Debloater-Ansatz, aber ich habe keinen Beweis dafür, dass er funktioniert. Es würde den Garantien des Sicherheitsmodells widersprechen. Vielleicht könntest du da mal recherchieren?

Diese Ansätze können nur funktionieren, wenn das Android SystemWebView nicht vorhanden ist, da Bromite SystemWebView denselben Paketnamen verwendet und die Überprüfung der APK-Signatur ansonsten fehlschlagen würde.

Soweit ich das verstanden habe, ist sich die Wiki-Seite der Auswirkungen auf das Sicherheitsmodell bewusst und der Debloater-Ansatz ist für Versionen vor Android 7.0 gedacht, bei denen es keine Möglichkeit gab, die WebView-Implementierung in den Entwicklereinstellungen manuell auszuwählen. Aus diesem Grund ist es erforderlich, alle anderen WebView-Anbieter mit einer höheren Priorität als com.android.webview deaktivieren, um das System zu zwingen, auf com.android.webview .

@SebiderSushi was ist hier zu tun? Soweit ich weiß, arbeitet daran niemand.

Ich bin mir nicht sicher was du meinst.

Was die WebView-Stub-Apk betrifft, muss (nach meinem derzeitigen Kenntnisstand) Folgendes getan werden:

Kompilieren Sie eine APK-Datei, die im Grunde nur ein Manifest mit dem richtigen Paketnamen enthält. Einen Referenz-Proof of Concept finden Sie hier .

Diese APK-Datei muss nur mit derselben Signatur wie die BromiteWebView-Release-Apks signiert werden und das Ganze wird erledigt, bis weitere Probleme aufgedeckt werden.

Es ist etwas komplexer als das:

• das SystemWebView muss mit dem aktuellen Paketnamen com.android.webview built erstellt werden
• es muss auch mit einem neuen Paketnamen erstellt werden
• der Stub muss gebaut werden

Ich kann das com.android.webview ewig beibehalten, aber gleichzeitig bin ich mir immer noch nicht sicher, in welchen Fällen es wichtig ist, diesen Paketnamen beizubehalten.

Sicher. Ich habe mich nur auf den Webview-Stub bezogen, da ich die Frage nach dem Paketnamen als ein anderes Thema sehe. Haben Sie sich diesbezüglich die Übersicht angesehen, die ich in meinem vorherigen Kommentar zum anderen Thema verlinkt habe? Ich habe einen Absatz über den Paketnamen und alle möglichen Überlegungen zusammengestellt, die ich dort sehe, und meine Schlussfolgerung ist, com.android.webview .

So wie es derzeit aussieht, denke ich, dass die verlorenen Vorteile der Verwendung von com.android.webview oder die Kosten für das Erstellen mit zwei Paketnamen die gewonnenen Vorteile eines eindeutigen Paketnamens überwiegen.

Natürlich könnte dieser Punkt überdacht werden, wenn das Team hinter einem weit verbreiteten benutzerdefinierten ROM (wie LineageOS) bereit wäre, einen eindeutigen Paketnamen für das Bromite WebView auf die Whitelist zu setzen.
Ich denke, wir sind uns alle einig, dass niemand von Google oder einem OEM erwartet, Bromite in AOSP oder ihrem Android-Zweig auf die Whitelist zu setzen.

com.android.webview könnte auf einer Reihe von ROMs auf der Whitelist stehen, aber definitiv ist es ohne Signatur in LineageOS und auch reinem AOSP auf der Whitelist, so dass einige OEMs dies möglicherweise so com.android.webview mit ihren Bauten.

Das macht viele ROMs, bei denen ein Magisk-Modul mit nur den Dateien system/app/webview/BromiteWebViewStub.apk und system/app/webview/replace ausreicht, um die Installation zu ermöglichen.
Die Alternative ohne Magisk wäre cat BromiteWebViewStub.apk > /system/app/webview/webview.apk oder etwas Äquivalentes.

Und bei Userdebug-Builds (alle offiziellen LineageOS-Builds!) wird die Stub-APK nicht einmal benötigt und ein rm -fr /system/app/webview reicht aus, um die Installation zu ermöglichen.

Der Punkt: All dies gilt auch für ältere Android-Versionen ohne RRO-Unterstützung.
Die Fälle, die dabei ausgelassen werden, sind Geräte, die com.android.webview nicht auf die Whitelist setzen und die ggf. eine RRO benötigen, um irgendwohin zu gelangen.

Natürlich wären einige Kennzahlen dazu besser als alle meine Annahmen. Daten aus der realen Welt über die Anzahl der ROMs, die in eine der oben genannten Kategorien fallen.

ist es ohne Signatur in LineageOS und auch reines AOSP auf der Whitelist

Ist das nicht eine Sicherheitslücke? Ich kann den AOSP-Fall verstehen, da OEMs ihn vor der Veröffentlichung "abschließen" sollen, aber wie können LineageOS-Versionen mit diesem offenen Problem veröffentlicht werden?

Und auf Userdebug-Builds (Alle offiziellen LineageOS-Builds!)

Ok, vielleicht verstehe ich nicht, wie diese für die Verwendung gehärtet sind. Meine Referenz für ein sicheres, nicht auf Lager befindliches Android-Betriebssystem ist GrapheneOS .

Wie es derzeit aussieht, denke ich, dass die verlorenen Vorteile der Verwendung von com.android.webview oder die Kosten für das Erstellen mit zwei Paketnamen die gewonnenen Vorteile eines eindeutigen Paketnamens überwiegen.

Natürlich könnte dieser Punkt überdacht werden, wenn das Team hinter einem weit verbreiteten benutzerdefinierten ROM (wie LineageOS) bereit wäre, einen eindeutigen Paketnamen für das Bromite WebView auf die Whitelist zu setzen.

Das Projekt hat – und sucht – keine Zugehörigkeit; Ich muss eine Entscheidung treffen, unabhängig davon, was ein anderes beliebtes - aber separates - Projekt entscheidet.

Lassen Sie es uns anders sagen: Wenn der Paketname org.bromite.webview , was wären die Probleme, um es auf LineageOS oder ähnlichem zu verwenden? Ich denke, Sie müssen sich keine Sorgen machen: Sie werden bereits mit weit geöffneten Berechtigungen ausgeführt, und Ihr Absatz über den Paketnamen scheint dies zu bestätigen.

Die einzigen verbleibenden Probleme sind:

1. die Unannehmlichkeiten der Änderung des Paketnamens für die aktuellen Benutzer
2. Einige ROMs haben möglicherweise eine ungepinnte com.android.webview Whitelist, und sie verlieren die Fähigkeit, die Webansicht zu installieren

(1) wird immer da sein, es ist kein guter Grund, niemals Veränderungen/Fortschritte vorzunehmen
Ich habe weder Beweise für (2) noch Zahlen, wie Sie sagten.

Hast du dir die Übersicht angesehen, die ich in meinem vorherigen Kommentar zu dem anderen Thema verlinkt habe?

Ja, aber ich komme zu anderen Schlussfolgerungen: Der Benutzer sollte in der Lage sein, die Webansicht auszuwählen, ohne in einen Bootmanager neu zu booten oder das ROM zu ändern, und die Wiederverwendung von Paketnamen ist aus Sicht der Funktionsweise von Android einfach falsch.

Auch hier sehe ich das Problem aus Sicherheitsgründen nicht.
Laut dem Chromium-Entwicklerkommentar, der in der ursprünglichen Wiki-Installationsanleitung zitiert und auf meiner Homepage rezitiert wurde:

WebView ist extrem privilegiert, da es in den Adressraum anderer Anwendungen geladen wird und somit Zugriff auf die Daten und Berechtigungen jeder einzelnen Anwendung hat, die es verwendet - daher kann es nur von jemandem ersetzt werden, der bereits die Fähigkeit besitzt, die Anwendung zu kompromittieren Sandbox sowieso: jemand mit Root-Zugriff oder der Builder des System-Images.

Als solches halte ich es für ausreichend, "die Sicherheitslücke zu füllen", indem entweder "Benutzer"-Builds geliefert oder ein Paket vorinstalliert wird, das die Stelle füllt. Da jeder, der das WebView noch ersetzen kann, immer noch Root-Zugriff benötigt, ist er so ziemlich schon da. Es sieht nicht ein, wie es für das Opfer noch schlimmer wird, wenn ein Angreifer neben mindestens vollem Zugriff auf die Systempartition auch die Webansicht ersetzen kann.

Und zu GrapheneOS: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
Sie sehen dies entweder nicht anders oder ersetzen diese Konfiguration zur Build-Zeit durch eine strikte. Ja, sie liefern wahrscheinlich user Build, aber das bedeutet nur, dass ein Angreifer sein bösartiges WebView einfach in der Systempartition platzieren muss.

Da GrapheneOS oder jedes andere aktuelle ROM zumindest auf Android Pie läuft, könnte ein Angreifer mit Root-Zugriff auch ein RRO platzieren und registrieren und die WebView-Whitelist durch alles ersetzen, was er möchte.
(Das heißt, nach einem Test, den ich gemacht habe, konnte ich einen RRO auf Pie and Ten registrieren, aber nicht auf Oreo oder darunter. Ich bin zwar erst am Anfang, RROs zu lernen, aber der Punkt steht definitiv für Android Ten. )

Hm. Okay, ich gehe jetzt auf deine Punkte im Detail ein und dann kannst du vielleicht darauf hinweisen, wie meine Erklärung im Wiki anders verstanden werden könnte oder in bestimmten Aspekten unklar sein könnte.
Was ich schon sehe ist, dass ich RROs dort nur vage behandelt habe: Das liegt an meiner Unkenntnis darüber.

Ich stimme zu: Die Verwendung eines eindeutigen Paketnamens ist das Richtige. Es ist praktisch, die WebView-Implementierung im Userspace auswählen zu können, und einige Anwendungsfälle können dies erfordern (obwohl ich keine davon kenne).

Ich denke, die Wiederverwendung von com.android.webview ist ein gültiger Kompromiss, zum einen, weil ich keine Anwendungsfälle sehe, die ein ständiges Wechseln der Implementierung erfordern, sondern wo der Benutzer einfach ein anderes WebView als täglichen Treiber verwenden möchte.
Und andererseits kann das Optimum, dass ein Benutzer Bromite WebView als Benutzer-App genauso wie Google WebView installieren und verwenden kann, ohne jemals sein System zu berühren, nur dann passieren, wenn eine Vielzahl von ROMs Bromite WebView eigenständig auf die Whitelist setzt.
Da wir das nie erwarten können, halte ich es für vernünftig, einen Kompromiss einzugehen, wie unten erläutert.

Erinnerung: Die folgenden Überlegungen sind ungültig, wenn RRO-Unterstützung vorhanden ist. Das heißt, wenn ältere Android-Versionen veraltet sind, sollte auf jeden Fall ein eindeutiger Paketname verwendet werden. Zu diesem Zeitpunkt bin ich mir nicht sicher, auf welchen Android-Versionen RROs zum Laufen gebracht werden könnten, aber während meiner Tests mit Marshmallow, Nougat, Oreo, Pie und Ten konnte ich nur eine RRO auf Pie und höher registrieren. Ich erinnere mich, dass @linuxandria Statet RROs theoretisch mit Android-Versionen ab 5.1 kompatibel gemacht werden könnten, also werden wir sehen, wie weit wir damit kommen werden.
In der Folge wird es jedoch unweigerlich zu dem Tag kommen, an dem die Verwendung von com.android.webview veraltet sein wird.

Solange Android-Versionen, bei denen wir die WebView-Whitelist nicht erfolgreich überschreiben können, von Bromite WebView unterstützt werden sollen, gilt folgende Überlegung:

Ohne eine benutzerdefinierte WebView-Whitelist besteht die einzige Hoffnung, ein Gerät zu unterstützen, darin, den Paketnamen com.android.webview , da er oft ohne Anheften einer Signatur auf die Whitelist gesetzt wird.

Die Verwendung eines anderen Paketnamens funktioniert nicht, nicht einmal auf LineageOS. Sie setzen lediglich Google WebView und eine Handvoll Google Chrome-Varianten (alle an eine Signatur angeheftet) und com.android.webview ohne Anheften einer Signatur auf die Whitelist .
Die einzige offene Tür mit LineageOS in Bezug auf WebView ist, dass sie userdebug Builds liefern, wodurch eine WebView-Installation ermöglicht wird, nachdem nur das Originalpaket aus dem System entfernt wurde, anstatt auch einen Stub oder das benutzerdefinierte Paket im System zu platzieren partitionieren. Was wiederum keine große Sache ist, wenn Sie bereits in der Lage sind, die ursprüngliche Webansicht zu entfernen. Als Benutzer oder Angreifer ist dies nur ein wenig aufwändiger.

Der Grund, warum ich LineageOS ständig anspreche

Diese Zahlen: https://www.lineageoslog.com/statistics

Ich halte LineageOS und LineageOS-basierte benutzerdefinierte ROMs für "wahrscheinlich einen bedeutenden Teil der Bromite WebView-Benutzerbasis". (Natürlich sind andere Projekte wie OmniROM wahrscheinlich auch für die Verwendung mit benutzerdefinierten Webansichten geeignet.)

Ich tue dies aus folgenden Überlegungen:

• Um heutzutage etwas benutzerdefiniertes zu installieren, benötigen Sie einen entsperrten Bootloader. Geräte, auf denen benutzerdefinierte ROMs ausgeführt werden, würden daher ebenfalls entsperrt.
• Benutzer, die gerne an ihren Geräten basteln und sie anpassen, verwenden möglicherweise auch eher ein benutzerdefiniertes ROM

• Und natürlich ist es mein persönlicher Anwendungsfall.

Offensichtlich wären alle tatsächlichen Benutzermetriken von Bromite WebView selbst schön. Solange wir keinen Zugriff darauf haben, sehe ich nur, dass wir Spekulationen betreiben, eine Münze werfen oder alles ablehnen können, wofür wir keinen RRO zum Laufen bekommen.
In diesem Sinne: Easy xkcd führt zum Beispiel von Zeit zu Zeit Benutzerbefragungen über Google Docs durch. Leider wird es ohne eine Benutzeroberfläche schwierig sein, einen guten Teil der Benutzer zu erwischen, denke ich.

TL; DR:

Meine current Überlegung ist "in der Lage zu sein, die Webansicht im Userspace zu ändern" im Vergleich zu "Geräten, die keine andere Möglichkeit haben, eine benutzerdefinierte Webansicht zu installieren, als com.android.webview ersetzen".

Zumal ich keine Anwendungsfälle sehe, die ersteres erfordern, bin ich überzeugt, dass letzteres viel mehr wiegt.

Die Frage läuft auf:
Gibt es einen erheblichen Teil der Geräte, auf denen Bromite WebView ausgeführt wird, bei denen wir keine Möglichkeit haben, die WebView-Whitelist zu überschreiben?

Und wieder hängt das, was ich gesagt habe, von unserem aktuellen Know-how zum Ersetzen der WebView-Whitelist ab. Wenn jemand neue und bessere Methoden findet, um die Whitelist auf realen Geräten zu ersetzen, wird sich die ganze Argumentation in Richtung eines eindeutigen Paketnamens verschieben.

Jedes Setup, bei dem die Whitelist überschrieben werden kann, kann von Bromite WebView ordnungsgemäß unterstützt werden.

Als solches halte ich es für ausreichend, "die Sicherheitslücke zu füllen", indem entweder "Benutzer"-Builds geliefert oder ein Paket vorinstalliert wird, das die Stelle füllt. Denn wer das WebView noch ersetzen kann, braucht dann noch Root-Zugriff

Ich dachte, dass Sie keinen Root-Zugriff benötigen, wenn das Paket da ist und keine Signatur vorhanden ist.

Und zu GrapheneOS: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
Sie sehen dies entweder nicht anders oder ersetzen diese Konfiguration zur Build-Zeit durch eine strikte. Ja, sie liefern wahrscheinlich user Build, aber das bedeutet nur, dass ein Angreifer sein bösartiges WebView einfach in der Systempartition platzieren muss.

Lassen Sie uns @thestinger fragen: Es gibt keine Möglichkeit, eine bösartige Webansicht (die dem Paketnamen auf der Whitelist entspricht) auf GrapheneOS ohne Root-Zugriff zu installieren, richtig?

Ohne eine benutzerdefinierte WebView-Whitelist besteht die einzige Hoffnung, ein Gerät zu unterstützen, darin, den Paketnamen com.android.webview , da er oft ohne Anheften einer Signatur auf die Whitelist gesetzt wird.

Sie haben vergessen zu erwähnen, dass der Benutzer auch über Root-Zugriff verfügen muss. Was ist mit dem Modifizieren des Betriebssystems durch framework-res.apk , um andere Webansichten zu ermöglichen? Kann es mit root allein gemacht werden (ich glaube nein)? Es kann jedoch immer mit Wiederherstellungszugriff durchgeführt werden, richtig?

Wenn jemand neue und bessere Methoden findet, um die Whitelist auf realen Geräten zu ersetzen, wird sich die ganze Argumentation in Richtung eines eindeutigen Paketnamens verschieben.

Ich denke, es ist möglich, jedes ROM zu modifizieren, um andere Webansichten über einen benutzerdefinierten Bootloader zu unterstützen; siehe https://forum.xda-developers.com/showpost.php?s=16f45eae40ceea4635e4433c72137749&p=81313655&postcount=11

Diese Zahlen: https://www.lineageoslog.com/statistics

Entschuldigung, Bromite ist nicht mit LineageOS verbunden.

• Und natürlich ist es mein persönlicher Anwendungsfall.

Das macht Sie voreingenommen; Ein großes Lob für das Aufdecken der Voreingenommenheit, aber ich muss immer noch eine Wahl treffen, die auf dem neutralen Fall basiert, z. B. jeder Benutzer, der ein beliebiges ROM verwendet.

Lassen Sie uns @thestinger fragen: Es gibt keine Möglichkeit, eine bösartige Webansicht (die dem Paketnamen auf der Whitelist entspricht) auf GrapheneOS ohne Root-Zugriff zu installieren, richtig?

Richtig, und es verwendet verifiziertes Booten. Das Betriebssystem wird von der Root of Trust verifiziert.

Und zu GrapheneOS: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
Sie sehen dies entweder nicht anders oder ersetzen diese Konfiguration zur Build-Zeit durch eine strikte. Ja, sie liefern wahrscheinlich Benutzer-Builds, aber das bedeutet nur, dass ein Angreifer sein bösartiges WebView einfach in der Systempartition platzieren müsste.

Da GrapheneOS oder jedes andere aktuelle ROM zumindest auf Android Pie läuft, könnte ein Angreifer mit Root-Zugriff auch ein RRO platzieren und registrieren und die WebView-Whitelist durch alles ersetzen, was er möchte.
(Das heißt, nach einem Test, den ich gemacht habe, konnte ich einen RRO auf Pie and Ten registrieren, aber nicht auf Oreo oder darunter. Ich bin zwar erst am Anfang, RROs zu lernen, aber der Punkt steht definitiv für Android Ten. )

Das ist unsinnig. Wie genau hilft eine redundante Signaturprüfung in jeder Situation? Wenn ein Angreifer das Betriebssystem erfolgreich ausgenutzt hat, um vollen Root-Zugriff zu erlangen, was ist dann relevant, wenn hier eine Signatur fest verdrahtet ist? Sie verstehen auch, dass GrapheneOS genau wie das Standard-Betriebssystem einen vollständigen verifizierten Bootvorgang hat, oder? Dafür ist es aber nicht besonders relevant...

Android verwendet Key-Pinning für jede einzelne App-Installation. Wenn eine App in das Systemimage integriert ist, wird der Schlüssel über die App, die in das Systemimage integriert wird, dauerhaft gepinnt. Es macht keinen Sinn, von einem Angriff zu sprechen, bei dem die App im Systemabbild ersetzt wird. Ein Angreifer müsste bereits vollen Root-Zugriff erhalten haben, um ihn wieder als beschreibbar einzubinden und zu ändern. Sie könnten auch die Whitelist ändern ... wie macht es Sinn, dies als Angriffsvektor vorzuschlagen? Außerdem wird es nur als Manipulation erkannt, indem es beim nächsten Booten so oder so überprüft wird. Verifiziertes Bootketten-Trust von der Firmware und verifiziert alle Betriebssystem-Images.

Die Angabe einer Signatur in config_webview_packages.xml ist für Fälle vorgesehen, in denen die App nicht im Betriebssystem enthalten ist. Sie listen entweder eine App auf, die im Betriebssystem gebündelt ist, ohne einen Schlüssel-Pin anzugeben, oder eine App, die nicht im Betriebssystem enthalten ist, mit einem Schlüssel-Pin auf. Das Auflisten eines Schlüssel-Pins ist eine Möglichkeit, die Sicherheit zu gewährleisten, obwohl er nicht in das Betriebssystem integriert ist. Es ist nicht die normale Art, diese Konfiguration zu verwenden. Es wäre für jeden unnötig kompliziert, diese Konfigurationsdatei ändern zu müssen, um den Schlüssel des gebündelten WebViews anzugeben, und ist nicht so implementiert. Das Betriebssystem bietet bereits eine Signaturprüfung für jedes installierte Paket.

Ich kann mir keinen Fall vorstellen, in dem die Verwendung von com.android.webview hilfreich wäre. Wenn bereits eine App gebündelt ist, können Sie sie nicht installieren. Wenn keine installiert ist, muss die Whitelist einen angehefteten Schlüssel haben. In jedem Fall benötigen Sie Unterstützung für Bromite, die in das Betriebssystem integriert ist. Um dies unter Beibehaltung des Sicherheitsmodells und des Aktualisierungssystems ordnungsgemäß zu tun, muss dies als Teil des Erstellens erfolgen, bevor ein signiertes Release generiert wird. Es in eine vorhandene Version zu hacken, indem die verifizierte Boot- und Update-Systemkompatibilität aufgegeben wird (wenn Sie Änderungen vornehmen, haben Sie inkrementelle Updates abgebrochen), ändert nichts wirklich etwas. Sie können die Ressourcen von binärem XML in XML konvertieren, es ändern und zurückkonvertieren. So oder so bauen Sie es in das Betriebssystem ein.

Sie listen entweder eine App auf, die im Betriebssystem gebündelt ist, ohne einen Schlüssel-Pin anzugeben, oder eine App, die nicht im Betriebssystem enthalten ist, mit einem Schlüssel-Pin auf.

Ich kann mir keinen Fall vorstellen, in dem die Verwendung von com.android.webview hilfreich wäre. Wenn bereits eine App gebündelt ist, können Sie sie nicht installieren.

Das einzige unsichere Szenario ist, wenn Pakete auf der Whitelist stehen und das ROM ohne installierte solche Pakete geliefert wird. Die vorherigen Diskussionen hier zu diesem Thema sind verwirrend, wenn sie diese Bedingung nicht explizit erwähnen.

Hier gibt es viele Hypothesen; Meine Begründung ist mehr oder weniger: Wenn com.android.webview für Nicht-Root- Benutzer solcher unsicheren ROMs von Vorteil ist, habe ich kein Interesse, sie zu unterstützen.

Also @SebiderSushi Ich denke, die Forschung kann in zwei Stämme aufgeteilt werden:

1. Optionen zur Installation des WebView ohne Root und einen entsperrten Bootloader (zB nicht verifizierter Bootvorgang)
2. Optionen um das WebView mit root zu installieren

Sie haben bereits viel recherchiert, was für mich sinnvoll wäre, wäre, dies in einer Art Benutzerhandbuch/Flussdiagramm anzuordnen; bei jedem Schritt sollten auch die Auswirkungen auf die Sicherheit klar sein.

Mir ist bewusst, dass die einzige Möglichkeit, eine Webansicht zu installieren, ohne das Sicherheitsmodell zu verletzen, darin besteht, sie zur Build-Zeit zu unterstützen.

Daher impliziere ich zu jeder Zeit entsperrte Bootloader (und folglich Root/vollen Systemzugriff), da dies der einzige realistische Weg ist, eine benutzerdefinierte Webansicht auf einem Endbenutzergerät zu installieren, ohne dafür ein vollständiges ROM zu erstellen.

Infolgedessen spreche ich nicht von Anwendungsfällen, die AVB erhalten.

Mir ist kein ROM bekannt, das Bromite-Unterstützung bündeln würde. Das meinte ich, als ich sagte

Natürlich könnte dieser Punkt überdacht werden, wenn das Team hinter einem weit verbreiteten benutzerdefinierten ROM (wie LineageOS) bereit wäre, einen eindeutigen Paketnamen für das Bromite WebView auf die Whitelist zu setzen.

Ich wollte zu keinem Zeitpunkt eine Zugehörigkeit andeuten, aber ohne dass so etwas passiert, bleibt der einzige verbleibende Anwendungsfall Benutzer mit entsperrten Bootloadern, die ihre Systempartitionen patchen oder Magisk-Module installieren oder was auch immer die Arbeit erledigt.

Ich kann mir keinen Fall vorstellen, in dem die Verwendung von com.android.webview hilfreich wäre. [...] Sie können die Ressourcen von binärem xml in xml konvertieren, es ändern und zurückkonvertieren. So oder so bauen Sie es in das Betriebssystem ein.

Gegenbeispiel:

• entsperrter Bootloader
• Benutzer-Build, der com.android.webview die Whitelist setzt, ohne eine Signatur anzuheften
• vorinstallierte Webansicht installiert als /system/app/webview/webview.apk
• keine RRO-Unterstützung (Android 6 oder so)

Ich kann Bromite WebView installieren, indem ich es ausführe
cat bromitewebview.apk > /system/app/webview/webview.apk in TWRP zum Beispiel.
Und ich kann dies booten und Bromite WebView verwenden.
Nur weil Bromite WebView derzeit com.android.webview

Wie würde ich die Webview-Whitelist in diesem Szenario ersetzen, um einen eindeutigen Paketnamen zu unterstützen, wenn das Patchen von framework-res.apk nicht funktioniert, weil ich es nicht mit dem Plattformschlüssel erneut signieren kann?

Lassen Sie uns @thestinger fragen: Es gibt keine Möglichkeit, eine bösartige Webansicht (die dem Paketnamen auf der Whitelist entspricht) auf GrapheneOS ohne Root-Zugriff zu installieren, richtig?

Dies gilt auch für LineageOS, auch wenn sie AVB nicht unterstützen.

Wie würde ich die Webview-Whitelist in diesem Szenario ersetzen, um einen eindeutigen Paketnamen zu unterstützen, wenn das Patchen von framework-res.apk nicht funktioniert, weil ich es nicht mit dem Plattformschlüssel erneut signieren kann?

Wenn diese Aussage falsch ist, dann yay.
Denn wenn eine benutzerdefinierte Whitelist auf jede Android-Version angewendet werden kann, die von Bromite WebView unterstützt wird, sehe ich dies als naheliegend für einen eindeutigen Paketnamen an.

Aber auch das habe ich die ganze Zeit gesagt.

Wie genau hilft eine redundante Signaturprüfung in jeder Situation? Wenn ein Angreifer das Betriebssystem erfolgreich ausgenutzt hat, um vollen Root-Zugriff zu erlangen, was ist dann relevant, wenn hier eine Signatur fest verdrahtet ist?

Das ist eigentlich auch mein Punkt und was ich aus diesem Grund zu @csagan5 sagen wollte:

ist es ohne Signatur in LineageOS und auch reines AOSP auf der Whitelist?

Ist das nicht eine Sicherheitslücke? Ich kann den AOSP-Fall verstehen, da OEMs ihn vor der Veröffentlichung "abschließen" sollen, aber wie können LineageOS-Versionen mit diesem offenen Problem veröffentlicht werden?

Es macht keinen Sinn, von einem Angriff zu sprechen, bei dem die App im Systemabbild ersetzt wird. Ein Angreifer müsste bereits vollen Root-Zugriff erhalten haben, um ihn wieder als beschreibbar einzubinden und zu ändern. Sie könnten auch die Whitelist ändern...

Und das habe ich auch ein paar Mal gesagt.

Ich bin mir nicht sicher, wie Sie diesen Paragaraph anders verstehen könnten:

Als solches halte ich es für ausreichend, "die Sicherheitslücke zu füllen", indem entweder "Benutzer"-Builds geliefert oder ein Paket vorinstalliert wird, das die Stelle füllt. Da jeder, der das WebView noch ersetzen kann, immer noch Root-Zugriff benötigt, ist er so ziemlich schon da. Es sieht nicht ein, wie es für das Opfer noch schlimmer wird, wenn ein Angreifer neben mindestens vollem Zugriff auf die Systempartition auch die Webansicht ersetzen kann.

Um zum Thema zurückzukommen:

Es läuft auf:
Gibt es einen erheblichen Teil der Geräte, auf denen Bromite WebView ausgeführt wird, bei denen wir keine Möglichkeit haben, die WebView-Whitelist zu überschreiben?

Nach meinem derzeitigen Kenntnisstand gibt es ROMs, bei denen die vorinstallierte Webview-APK im System ausgetauscht werden kann und es funktioniert.
Nach meinem derzeitigen Kenntnisstand haben wir keine bekannte und zuverlässige Methode zum Ändern der WebView-Whitelist auf diesen ROMs, um etwas anderes als com.android.webview wenn keine Unterstützung für das Runtime Resource Overlay vorhanden ist.

Wenn ich damit falsch liege, wenn das Patchen von framework-res.apk zumindest dann funktioniert, wenn der Webview-Apk-Ersatz funktioniert (da das System auch die Signatur dieser APK überprüfen könnte oder sollte oder nicht?) oder wenn wir eine neue Methode finden die Whitelist zu überschreiben, dann sehe ich nichts mehr, was einem eindeutigen Paketnamen entgegenstehen würde, was ich wiederum auch für richtig halte.

EDIT: Auch hier ist es immer noch eine Option, jede Android-Version, bei der die Whitelist nicht zuverlässig überschrieben werden kann, offen abzulehnen (aus der Sicht von Bromiet WebViews).

Es in eine vorhandene Version zu hacken, indem die verifizierte Boot- und Update-Systemkompatibilität aufgegeben wird (wenn Sie Änderungen vornehmen, haben Sie inkrementelle Updates abgebrochen), ändert nichts wirklich etwas.

@thestinger Mit Magisk können Sie Systemdateien ersetzen, ohne inkrementelle Updates zu unterbrechen und vielleicht sogar ohne AVB (vollständig) zu boot und userdata bleiben unverändert.

Der Kern von AVB ist die Überprüfung von vbmeta und was es über Hashes referenziert.

Hier gibt es viele Hypothesen; meine Begründung ist mehr oder weniger: Wenn com.android.webview für Nicht-Root-Benutzer solcher unsicheren ROMs von Vorteil ist, habe ich kein Interesse, sie zu unterstützen.

@csagan5 Sie beziehen sich auf ROMs, die com android.webview auf die Whitelist setzen, ohne eine Signatur anzuheften, obwohl kein com.android.webview Paket vorinstalliert ist, wodurch die Installation eines beliebigen com.android.webview WebView-Anbieters als Benutzer-App ohne Manipulation möglich ist das system habe ich das richtig verstanden?

Ich denke auch, dass dies ein Szenario ist, das nicht unterstützt werden muss und habe es irgendwann als "unsicher" und "höchst unwahrscheinlich" bezeichnet.

Ich bin mir nicht sicher, ob Sie das tatsächlich tun können.

Auf Android 7 und höher funktioniert dies nur bei Userdebug-Builds, ist aber möglich.

Auf Android 6 und darunter denke ich, dass es grundsätzlich möglich ist (die WebView-Whitelist funktionierte damals auch anders).

Ich habe tatsächlich ein Gerät, das zu diesem Szenario passt:
Das Lollipop-ROM auf dem OnePlus X hatte dieses Sicherheitsproblem. Sie haben kein com.android.webview Paket gebündelt, obwohl es auf die Whitelist gesetzt wurde, und es ist möglich, Bromite-Webview zu installieren, ohne das System zu manipulieren. Ich habe nicht überprüft, ob dies auch als userdebug Build veröffentlicht wurde, aber es ist ein reales Gerät, das in das Szenario passt. Aber wieder sehr unwahrscheinlich.

Wenn wir über so alte Geräte sprechen, ist es vielleicht auch erwähnenswert, dass auf diesen Geräten kein verifiziertes Booten vorhanden ist.
Denken Sie daran, dass Bromite WebView auch mit minApiVersion von 19 .

Dadurch wurde mir klar, dass ich in einem früheren Kommentar etwas falsch verstanden habe, ich habe ihn gelöscht, weil er ungültig war und werde ihn jetzt umformulieren:

Also @SebiderSushi Ich denke, die Forschung kann in zwei Stämme aufgeteilt werden:

1. Optionen zur Installation des WebView ohne Root und einen entsperrten Bootloader (zB nicht verifizierter Bootvorgang)
2. Optionen um das WebView mit root zu installieren

Ich sehe nicht, wie diese Unterscheidung bestehen könnte, denn:

• Wenn es um einen verifizierten Boot-Prozess geht, wäre die einzige Möglichkeit, die Bromit-Unterstützung durch den Builder in das ROM zu backen, Root würde nicht helfen.
• Wenn es sich um ein Gerät ohne verifizierte Boot-Unterstützung oder einen entsperrten Bootloader handelt, kann das Systemabbild auf jede erforderliche Weise manipuliert werden.

Um zusammenzufassen:

• Das Ändern der Webview-Whitelist muss von demjenigen durchgeführt/unterstützt werden, der das System-Image erstellt, oder es verstößt gegen das Sicherheitsmodell
• Das Ändern der Webview-Whitelist erfordert das Ändern des Inhalts der Systempartition, zumindest so wie er zur Laufzeit wirksam ist
• wie ein Benutzer die Möglichkeit erhält, sein System zu ändern, liegt außerhalb unseres Verantwortungsbereichs. Sie könnten Runtime-Root-Zugriff verwenden, um Dateien in ihrer physischen Systempartition zu platzieren, sie könnten ein gepatchtes System per Fastboot flashen, eine benutzerdefinierte Wiederherstellung verwenden, um ihren Speicher zu manipulieren, andere Mittel wie Magisk oder buchstäblich was auch immer, aber es macht keinen Unterschied für die Methode zum Überschreiben der Webview-Whitelist, soweit ich weiß

Solange wir uns zur Laufzeit nicht in das Framework hacken, um ein benutzerdefiniertes Webview-Paket als Standortanbieter zu ermöglichen.

Okay, ich interessiere mich gerade zu sehr dafür, buchstäblich möchte ich nur sagen, dass wir optimalerweise sollten

• eine Möglichkeit haben, einen benutzerdefinierten Paketnamen auf allen Android-Geräten / -Versionen, die von Bromite Webview unterstützt werden, auf die Whitelist zu setzen, was auch immer diese Methode sein mag.

ODER

• Geben Sie den Bromit-Support offen (ich weiß, dass der Support dafür nie offiziell war) für alle Android-Versionen / -Geräte, bei denen dies nicht möglich ist. Dies bedeutet nicht unbedingt, dass die minApiVersion geändert werden muss, da Benutzer immer noch versuchen können, das Überschreiben der Whitelist selbst herauszufinden, aber diese echte Konsequenz muss anerkannt werden, wenn mit einem eindeutigen Paketnamen weitergegangen wird.

ODER

• Veröffentlichen Sie die Webansicht mindestens mit com.android.webview als Paketnamen

Es sollte so schnell wie möglich ein eindeutiger Paketname verwendet werden, aber ich denke, dass diese Aspekte die veraltete Version des Paketnamens com.android.webview in Bromite WebView-Versionen blockieren sollten.

Sobald diese blockierenden Aspekte behoben sind, sehe ich nichts anderes, was eine Verwerfung des com.android.webview Paketnamens aufhalten würde.

Im Grunde sehe ich hier einen Kompromiss.
Wie es derzeit aussieht, konnte ich auf Android 7 und 8 kein Runtime Resource Overlay registrieren. Das Patchen der framework-res.apk habe ich noch nicht ausprobiert, bezweifle aber, dass es zuverlässig funktioniert. Zumindest gibt es dafür keine allgemeine Lösung, ein zuverlässiger Installer wäre notwendig, da nicht jeder Benutzer in der Lage ist, dies manuell zu tun.
Andererseits bietet die Verwendung eines eindeutigen Paketnamens nur dann einen echten Vorteil, wenn ROMs oder Vendoren Bromite WebView auf die richtige Weise auf die Whitelist setzen, und ich erwarte nicht, dass dies in relevantem Umfang geschieht.
Das sind alles Gründe, warum ich denke, dass es com.android.webview zu bleiben und die Installation von Bromite-Webviews effektiv zu ermöglichen, ohne die Whitelist auf einer Reihe von Geräten durch Ersetzen des Webviews patchen zu müssen apk im System mit der Bromite apk. Dieser spezielle Prozess kann vereinfacht werden, indem ein Stub-APK für diesen Schritt verwendet wird. Wenn die Webview-Whitelist gesteuert werden kann, wird die Stub-Apk nicht mehr benötigt.

bei jedem Schritt sollten auch die Auswirkungen auf die Sicherheit klar sein.

Dies sind die Sicherheitsauswirkungen, die ich bei der Installation von Bromite WebView sehe:

• Verwenden von Bromite WebView
  -> Sie müssen @csagan5 vertrauen, da jede Webansicht in den Adressraum der Anwendungen geladen wird, die sie verwenden. (Gibt es nicht eine Möglichkeit, das in AOSP zu beheben? Ich meine, das ist der Grund für die Einschränkungen der Webview-Installation ...)
• Bromite WebView mit einem eindeutigen Paketnamen, der vom ROM ordnungsgemäß unterstützt wird
  -> Vertraust du deinem ROM?
• Ändern der Whitelist für WebView-Anbieter
  -> Die neue Whitelist kann WebViews zulassen, denen Sie nicht vertrauen, oder WebViews ohne Signatur anheften, die nicht vorinstalliert sind, während gleichzeitig ein userdebug Build von AOSP ausgeführt wird.
• Platzieren von Dateien in Ihrer Systempartition
  -> Die üblichen Implikationen für das, was hoffentlich jedem bewusst ist, der dies tut und die IMO nicht in der Verantwortung einer Webview-Installationsanleitung liegen.
• Entsperren Ihres Bootloaders
  -> Siehe vorherige Erklärung
• Verwenden von Drittanbieter-Software zum Installieren von Bromite WebView in Ihrem System
  -> Siehe vorherige Erklärung

Um zum Thema zurückzukommen:

Es läuft auf:
Gibt es einen erheblichen Teil der Geräte, auf denen Bromite WebView ausgeführt wird, bei denen wir keine Möglichkeit haben, die WebView-Whitelist zu überschreiben?

Nach meinem derzeitigen Kenntnisstand gibt es ROMs, bei denen die vorinstallierte Webview-APK im System ausgetauscht werden kann und es funktioniert.
Nach meinem derzeitigen Kenntnisstand haben wir keine bekannte und zuverlässige Methode zum Ändern der WebView-Whitelist auf diesen ROMs, um etwas anderes als com.android.webview wenn keine Unterstützung für das Runtime Resource Overlay vorhanden ist.

Wenn ich damit falsch liege, wenn das Patchen von framework-res.apk zumindest dann funktioniert, wenn der Webview-Apk-Ersatz funktioniert (da das System auch die Signatur dieser APK überprüfen könnte oder sollte oder nicht?) oder wenn wir eine neue Methode finden die Whitelist zu überschreiben, dann sehe ich nichts mehr, was einem eindeutigen Paketnamen entgegenstehen würde, was ich wiederum auch für richtig halte.

EDIT: Auch hier ist es immer noch eine Option, jede Android-Version, bei der die Whitelist nicht zuverlässig überschrieben werden kann, offen abzulehnen (aus der Sicht von Bromiet WebViews).

Paar Dinge

Sofern Ihr ROM nicht mit Testschlüsseln signiert ist, können Sie Framework-Res nicht erneut signieren, und wenn dies der Fall ist, müssen Sie es dennoch signieren
Android überprüft Framework-Res und Bootloop der meisten Geräte, wenn die Signatur falsch ist

Derzeit versucht mein Modul, das Overlay nur für Stock-ROMs zu aktivieren, aber ich finde auf a10, dass einige Zoll auch nicht die erforderliche Whitelist haben oder die Requisiten, nach denen ich suche, nicht existieren, also plane ich, sie immer aufzunehmen das Overlay zum Überschreiben der Whitelist.

Auf jeden Fall erfordert es in 99,9999999999999% der Fälle Root oder einen entsperrten Bootloader, sodass meine Methode für alle Paketnamen leicht zu aktualisieren wäre. Andere Installationsmethoden sind nicht so sehr z, obwohl sie ohnehin dazu neigen, Probleme zu haben

Sie listen entweder eine App auf, die im Betriebssystem gebündelt ist, ohne einen Schlüssel-Pin anzugeben, oder eine App, die nicht im Betriebssystem enthalten ist, mit einem Schlüssel-Pin auf.

Ich kann mir keinen Fall vorstellen, in dem die Verwendung von com.android.webview hilfreich wäre. Wenn bereits eine App gebündelt ist, können Sie sie nicht installieren.

Das einzige unsichere Szenario ist, wenn Pakete auf der Whitelist stehen und das ROM ohne installierte solche Pakete geliefert wird. Die vorherigen Diskussionen hier zu diesem Thema sind verwirrend, wenn sie diese Bedingung nicht explizit erwähnen.

Hier gibt es viele Hypothesen; Meine Begründung ist mehr oder weniger: Wenn com.android.webview für Nicht-Root- Benutzer solcher unsicheren ROMs von Vorteil ist, habe ich kein Interesse, sie zu unterstützen.

Also @SebiderSushi Ich denke, die Forschung kann in zwei Stämme aufgeteilt werden:

1. Optionen zur Installation des WebView ohne Root und einen entsperrten Bootloader (zB nicht verifizierter Bootvorgang)
2. Optionen um das WebView mit root zu installieren

Sie haben bereits viel recherchiert, was für mich sinnvoll wäre, wäre, dies in einer Art Benutzerhandbuch/Flussdiagramm anzuordnen; bei jedem Schritt sollten auch die Auswirkungen auf die Sicherheit klar sein.

Ich habe noch kein Stock-ROM getroffen, das com.android.webview auf die Whitelist setzt, geschweige denn ohne eine angeheftete Signatur (ich denke, ein früherer Pixel-A10-Build hat dies getan, kann aber nicht mehr überprüfen) und Stock-ROMs wären Benutzer-Builds, ohne dass die Ausführung von a möglich wäre webview als Benutzer-App.
Obwohl einige OEMs AVB möglicherweise nicht vollständig durchsetzen, wodurch wir Änderungen vornehmen können, wird es immer schwieriger, eine Nicht-Datenpartition rw zu mounten (siehe: EROFS, ext4-Dedup, dynamische Partitionen usw.).

Infolgedessen spreche ich nicht von Anwendungsfällen, die AVB erhalten.

Mir ist kein ROM bekannt, das Bromite-Unterstützung bündeln würde. Das meinte ich, als ich sagte

Natürlich könnte dieser Punkt überdacht werden, wenn das Team hinter einem weit verbreiteten benutzerdefinierten ROM (wie LineageOS) bereit wäre, einen eindeutigen Paketnamen für das Bromite WebView auf die Whitelist zu setzen.

Zu keinem Zeitpunkt wollte ich eine Zugehörigkeit andeuten, aber ohne dass so etwas passiert, bleibt der einzige verbleibende Anwendungsfall Benutzer mit entsperrten Bootloadern, die ihre Systempartitionen patchen oder Magisk-Module installieren oder was auch immer die Arbeit erledigt.

Einige benutzerdefinierte ROMs unterstützen AVB vollständig und theoretisch könnten Sie, wenn Sie selbst erstellt haben, den Magisk-gepatchten Boot mit Ihren Schlüsseln signieren und Root haben, aber den Bootloader gesperrt haben

Ich kann mir keinen Fall vorstellen, in dem die Verwendung von com.android.webview hilfreich wäre. [...] Sie können die Ressourcen von binärem xml in xml konvertieren, es ändern und zurückkonvertieren. So oder so bauen Sie es in das Betriebssystem ein.

Gegenbeispiel:

• entsperrter Bootloader
• Benutzer-Build, der com.android.webview die Whitelist setzt, ohne eine Signatur anzuheften
• vorinstallierte Webansicht installiert als /system/app/webview/webview.apk
• keine RRO-Unterstützung (Android 6 oder so)

Ich kann Bromite WebView installieren, indem ich es ausführe
cat bromitewebview.apk > /system/app/webview/webview.apk in TWRP zum Beispiel.
Und ich kann dies booten und Bromite WebView verwenden.
Nur weil Bromite WebView derzeit com.android.webview

Wie würde ich die Webview-Whitelist in diesem Szenario ersetzen, um einen eindeutigen Paketnamen zu unterstützen, wenn das Patchen von framework-res.apk nicht funktioniert, weil ich es nicht mit dem Plattformschlüssel erneut signieren kann?

Webview unter 7 ist in seiner Funktionsweise sehr unterschiedlich und ich biete keinen offiziellen Support, obwohl ich Berichte habe, dass es auf einigen 6.0-ROMs funktioniert

Dadurch wurde mir klar, dass ich in einem früheren Kommentar etwas falsch verstanden habe, ich habe ihn gelöscht, weil er ungültig war und werde ihn jetzt umformulieren:

Also @SebiderSushi Ich denke, die Forschung kann in zwei Stämme aufgeteilt werden:

1. Optionen zur Installation des WebView ohne Root und einen entsperrten Bootloader (zB nicht verifizierter Bootvorgang)
2. Optionen um das WebView mit root zu installieren

Ich sehe nicht, wie diese Unterscheidung bestehen könnte, denn:

• Wenn es um einen verifizierten Boot-Prozess geht, wäre die einzige Möglichkeit, die Bromit-Unterstützung durch den Builder in das ROM zu backen, Root würde nicht helfen.
• Wenn es sich um ein Gerät ohne verifizierte Boot-Unterstützung oder einen entsperrten Bootloader handelt, kann das Systemabbild auf jede erforderliche Weise manipuliert werden.

Um zusammenzufassen:

• Das Ändern der Webview-Whitelist muss von demjenigen durchgeführt/unterstützt werden, der das System-Image erstellt, oder es verstößt gegen das Sicherheitsmodell
• Das Ändern der Webview-Whitelist erfordert das Ändern des Inhalts der Systempartition, zumindest so wie er zur Laufzeit wirksam ist
• wie ein Benutzer die Möglichkeit erhält, sein System zu ändern, liegt außerhalb unseres Verantwortungsbereichs. Sie könnten Runtime-Root-Zugriff verwenden, um Dateien in ihrer physischen Systempartition zu platzieren, sie könnten ein gepatchtes System per Fastboot flashen, eine benutzerdefinierte Wiederherstellung verwenden, um ihren Speicher zu manipulieren, andere Mittel wie Magisk oder buchstäblich was auch immer, aber es macht keinen Unterschied für die Methode zum Überschreiben der Webview-Whitelist, soweit ich weiß

Wir gehen von einer nicht manipulierten Systempartition aus, und da Magisk das System nicht manipuliert, können wir auch davon ausgehen, dass eine Handvoll Benutzer AVB erzwingen müssen, wenn die richtigen Schritte unternommen werden

Ab v5.0.1 habe ich den Nicht-Magisk-Support eingestellt, obwohl ich evaluieren werde, ihn zurückzubringen, wenn genug Leute ihn brauchen

Auf jeden Fall erfordert es in 99,9999999999999% der Fälle Root oder einen entsperrten Bootloader, sodass meine Methode für alle Paketnamen leicht zu aktualisieren wäre. Andere Installationsmethoden sind nicht so sehr z, obwohl sie ohnehin dazu neigen, Probleme zu haben

Ich interessiere mich für die anderen Installationsmethoden.

Auf jeden Fall erfordert es in 99,9999999999999% der Fälle Root oder einen entsperrten Bootloader, sodass meine Methode für alle Paketnamen leicht zu aktualisieren wäre. Andere Installationsmethoden sind nicht so sehr z, obwohl sie ohnehin dazu neigen, Probleme zu haben

Ich interessiere mich für die anderen Installationsmethoden.

Ich denke, nanodroid hat ein Installationsprogramm, aber es schiebt das APK nur in /system an seinen Platz.

Und natürlich gibt es die manuelle Ausschneide- und Einfügemethode, aber da die Bilder des RO-Systems zur Norm werden, und um AVB / dm-verity nicht auszulösen, es sei denn, es ist notwendig, würde ich von dieser Methode abraten :P

Heute habe ich herausgefunden, dass eine Möglichkeit zum Abrufen des signature Strings, der in die Webview-Whitelist aufgenommen werden muss, wie folgt ist:
keytool -printcert -rfc -jarfile arm_SystemWebView.apk

(Ich habe meine entsprechende Wiki-Seite aktualisiert, um diese Informationen aufzunehmen)

Noch eine Anmerkung: Ich habe gerade apktool , um den Paketnamen der Bromite-Webansicht zu ändern. Es stellte sich heraus, dass es tatsächlich funktioniert, nur die package und die Namen der 2 Anbieter im Manifest zu ändern und dann neu zu kompilieren, und ich kann Websites durch das Paket anzeigen, das ich auf diese Weise manipuliert und installiert habe.

Wenn es keine tiefgreifenden Probleme gibt, könnte das Erstellen mit zwei Paketnamen durch Ausführen einiger Shell-Befehle vor dem Erstellen erreicht werden - der erhöhte Aufwand würde sich nur auf die Erstellungszeit und die Veröffentlichungslogistik beschränken.

Was denkst du @csagan5 ? Würden Sie mit der Veröffentlichung mit zwei Paketnamen beginnen, wenn diese Theorie Bestand hat?
Oder vielleicht reicht es gerade aus, Bromit parallel auf lokalen Entwicklungsgeräten zu installieren...

Das Ändern der package & der Namen der 2 Anbieter im Manifest und dann das Neukompilieren funktioniert tatsächlich

Was neu kompilieren? Es funktioniert mit welcher Art von Framework-res.apk?

Würden Sie mit der Veröffentlichung mit zwei Paketnamen beginnen, wenn diese Theorie Bestand hat?

Ich muss sowieso auf den neuen Paketnamen umsteigen, der einzige unklare Teil ist, wie man Migrationsanweisungen für all die verschiedenen möglichen Installationen bereitstellt. Ich kann beide für eine Weile freigeben, aber ich muss vorher Anweisungen haben.

Das Ändern der package & der Namen der 2 Anbieter im Manifest und dann das Neukompilieren funktioniert tatsächlich

Was neu kompilieren? Es funktioniert mit welcher Art von Framework-res.apk?

Ich habe damit die Webansicht gemeint, da die Änderung von Framework-Res im Allgemeinen dazu führt, dass ein Gerät nicht mehr bootet

Das Ändern der package & der Namen der 2 Anbieter im Manifest und dann das Neukompilieren funktioniert tatsächlich

Was neu kompilieren? Es funktioniert mit welcher Art von Framework-res.apk?

Neukompilieren des Bromite WebView. Ich bezog mich nur auf die Möglichkeit, den Bromite WebView-Paketnamen ohne lästige tiefgreifende Änderungen an etwas anderem als dem Manifest zu ändern, wodurch der Aufwand minimiert wird, mit zwei Paketnamen gleichzeitig zu veröffentlichen. Entschuldigung, wenn dies keine neuen Informationen für Sie waren.

Würden Sie mit der Veröffentlichung mit zwei Paketnamen beginnen, wenn diese Theorie Bestand hat?

Ich muss sowieso auf den neuen Paketnamen umsteigen, der einzige unklare Teil ist, wie man Migrationsanweisungen für all die verschiedenen möglichen Installationen bereitstellt. Ich kann beide für eine Weile freigeben, aber ich muss vorher Anweisungen haben.

Aber da es keine Benutzerdaten gibt, kommt es darauf an, das neue Paket zu installieren und dieses als Webview-Anbieter auszuwählen, also geht es hauptsächlich darum, wie man die Nachrichten an jeden Benutzer bringt, oder?

Wie viel Aufwand wäre es, den Bromite-Browser mit Unterstützung auch als Webview-Anbieter zu kompilieren?

Wie viel Aufwand wäre es, den Bromite-Browser mit Unterstützung auch als Webview-Anbieter zu kompilieren?

Etwas sinnlos, da Browser und Webview bei 10+ in Upstream-Chrom getrennt sind

Sie sind nicht wirklich getrennt, sondern in 3 APKs unterteilt: Browser, WebView und eine Bibliotheks-Apk, die den größten Teil des Codes bereitstellt, der zwischen ihnen geteilt wird.

Das eigenständige WebView-Target ist absolut modern und wird dennoch vollständig unterstützt. Die eigenständigen Browser-APK-Ziele sind nicht für die Verwendung auf modernen Geräten vorgesehen. Wenn Sie vermeiden möchten, dass die Bibliothek aufgeteilt wird, während es sich dennoch um einen modernen Build handelt, müssen Sie ein neues Ziel erstellen.

Sie sind nicht wirklich getrennt, sondern in 3 APKs unterteilt: Browser, WebView und eine Bibliotheks-Apk, die den größten Teil des Codes bereitstellt, der zwischen ihnen geteilt wird.

Für unsere Absichten separate Pakete separate Apps, obwohl ich mir Trichrome vs Monochrome bewusst bin

Wir gehen davon aus, dass die Trichrome-Bibliothek auf Geräten verfügbar ist, die sie benötigen, und machen uns nur Sorgen um die Webansicht und in gewissem Maße den Browser

Die Bibliothek wird vom Browser und den WebView-Apks verwendet - sonst nichts. Es stellt den Großteil des Codes bereit.

Die Bibliothek wird vom Browser und den WebView-Apks verwendet - sonst nichts. Es stellt den Großteil des Codes bereit.

Nun ja was ich sage :)

Wie viel Aufwand wäre es, den Bromite-Browser mit Unterstützung auch als Webview-Anbieter zu kompilieren?

Meine Motivation hinter dieser Frage war die folgende Idee:
Der Bromite-Browser hat einen eigenen Paketnamen, sodass er bereits richtig auf die Whitelist gesetzt werden kann. Wenn es Webview-Funktionen bereitstellen könnte, sollten die meisten Benutzer nach der Installation in Ordnung sein.
Außerdem würde dies für Benutzer sowohl der Bromite-Webansicht als auch des Bromite-Browsers die Speicher- und Bandbreitennutzung reduzieren.

Zugegeben, das Debuggen der Standalone-Webansicht parallel zur Installation eines vorgelagerten Chromium-Webview-Pakets wäre immer noch unmöglich.

Was Trichrome vs. Monochrome angeht: Sie sind nur beide Methoden zum Deduplizieren von Code, oder? Und sie sind beide gültig und funktionieren, sogar auf Android 10+?
Zumindest habe ich diesen XDA-Beitrag so gelesen, mit den Vorteilen gegenüber Monochrome, dass Trichrome "weniger seltsame Sonderfälle und Fehler" hat.

Nein, es ist nicht einfach eine Wahl zwischen verschiedenen Möglichkeiten, Code zu teilen.

Wie viel Aufwand wäre es, den Bromite-Browser mit Unterstützung auch als Webview-Anbieter zu kompilieren?

Meine Motivation hinter dieser Frage war die folgende Idee:
Der Bromite-Browser hat einen eigenen Paketnamen, sodass er bereits richtig auf die Whitelist gesetzt werden kann. Wenn es Webview-Funktionen bereitstellen könnte, sollten die meisten Benutzer nach der Installation in Ordnung sein.
Außerdem würde dies für Benutzer sowohl der Bromite-Webansicht als auch des Bromite-Browsers die Speicher- und Bandbreitennutzung reduzieren.

Zugegeben, das Debuggen der Standalone-Webansicht parallel zur Installation eines vorgelagerten Chromium-Webview-Pakets wäre immer noch unmöglich.

Was Trichrome vs. Monochrome angeht: Sie sind nur beide Methoden zum Deduplizieren von Code, oder? Und sie sind beide gültig und funktionieren, sogar auf Android 10+?
Zumindest habe ich diesen XDA-Beitrag so gelesen, mit den Vorteilen gegenüber Monochrome, dass Trichrome "weniger seltsame Sonderfälle und Fehler" hat.

Trichrome ist Android 10+, Monochrom ist =<9

Das vorgelagerte Build-System definiert auch keine eigenständigen Browserziele für modernes Android. Wenn Sie das möchten, müssen Sie sie selbst definieren, da Sie sonst Builds bereitstellen, die die moderne Plattform nicht vollständig unterstützen.

Für WebView wird das eigenständige WebView-Ziel in allen unterstützten Versionen vollständig unterstützt. Wenn Sie den Code mit dem Browser teilen möchten, wird Trichrome auf Android 10+ und Monochrome für frühere Versionen verwendet (seit der Unterstützung). Monochrome wird unter Android 10+ nicht unterstützt und Trichrome wird vor Android 10 nicht unterstützt.

Es ist falsch, ChromeModernPublic unter Android 7+ zu verwenden. Sie müssen Ihr eigenes Ziel für einen eigenständigen Browser definieren. Es wird funktionieren, aber es unterstützt nicht die modernen Plattformfunktionen, einschließlich Sicherheitsverbesserungen, die an die API-Ebene gebunden sind.

Es ist ähnlich falsch, Monochrome auf Android 10+ zu verwenden, und es funktioniert überhaupt nicht als WebView-Anbieter. Es bietet nur einen funktionierenden Browser mit dem gleichen Problem wie ChromeModernPublic, mit einer weniger alten Ziel-API-Ebene.

Die Bibliothek wird vom Browser und den WebView-Apks verwendet - sonst nichts. Es stellt den Großteil des Codes bereit.

APKs können .so Bibliotheken bündeln und wenn sie genau gleich sind, werden sie im Speicher geteilt (wie jedes Linux), wodurch der Speicherbedarf für beide Apps reduziert wird.

Es ist falsch, ChromeModernPublic unter Android 6+ zu verwenden. Sie müssen Ihr eigenes Ziel für einen eigenständigen Browser definieren. Es wird funktionieren, aber es unterstützt nicht die modernen Plattformfunktionen, einschließlich Datenschutz- / Sicherheitsverbesserungen, die an die Ziel-API-Ebene gebunden sind.

@thestinger ChromeModernPublic ist nicht das richtige Ziel für einen eigenständigen Browser? Was verwendest du für Vanadium? Ich habe mich immer auf https://chromium.googlesource.com/chromium/src/+/master/docs/android_build_instructions.md#Multiple -Chrome-Targets bezogen, was bei den Anwendungsfällen etwas knapp ist.

APKs können .so-Bibliotheken bündeln und wenn sie genau gleich sind, werden sie im Speicher geteilt (wie bei jedem Linux), wodurch der Speicherbedarf für beide Apps reduziert wird

TrichromeLibrary macht dies sowohl mit der nativen Bibliothek als auch mit anderen Ressourcen. Es verwendet die Standardinfrastruktur für die Verwendung einer APK als Bibliothek (die über nur eine native Bibliothek hinausgeht) auf eine Weise, die ordnungsgemäß authentifiziert ist.

@thestinger ChromeModernPublic ist nicht das richtige Ziel für einen eigenständigen Browser? Was verwendest du für Vanadium? Ich habe mich immer auf https://chromium.googlesource.com/chromium/src/+/master/docs/android_build_instructions.md#Multiple -Chrome-Targets bezogen, was bei den Anwendungsfällen etwas knapp ist.

@csagan5 Es gibt kein modernes eigenständiges keins definiert wurde. Vanadium verwendet die Trichrome-Targets. TrichromeChrome + TrichromeLibrary ohne Versand TrichromeWebView ist die einzige Möglichkeit, einen modernen Browser zu erhalten, der nur die Upstream-Ziele verwendet. Wir verwenden die 64_32-Version der Targets, damit 64-Bit nicht nur unterstützt, sondern gegenüber 32-Bit auch bevorzugt wird, damit alle Browserprozesse als 64-Bit und die WebView-Renderer als 64-Bit ausgeführt werden.

Sie müssten selbst ein modernes eigenständiges Browserziel erstellen, um es ohne die TrichromeLibrary-Aufteilung zu haben. Ich bin mir nicht sicher, wie viele Änderungen es über targetSdkVersion hinaus gibt. Die Verwendung der 64_32-Ziele ist jetzt auch der richtige Weg, um 64-Bit-Prozesse zu bevorzugen, und das ist Teil der Trichrome-Build-Infrastruktur. Sie können Trichrome ohne WebView verwenden (indem Sie einfach die Browser- und Bibliotheksapk verwenden), aber es ist nicht so eingerichtet, dass sie ohne die Bibliothek als einzelne Browserapk erstellt wird.

Modern bedeutet nicht wirklich modern - es bedeutete modern zu der Zeit, als es existierte, verglichen mit dem älteren. Es wurde durch Monochrome und dann Trichrome ersetzt. Chrome wird nie als eigenständiger Browser ohne WebView ausgeliefert, daher gibt es kein Upstream-Ziel für etwas, das sie nie verwenden. Es ist durchaus möglich, es zu machen, aber sie tun es nicht, da sie keine Verwendung dafür haben.

Wir verwenden die 64_32-Version der Targets, damit 64-Bit nicht nur unterstützt, sondern gegenüber 32-Bit auch bevorzugt wird, damit alle Browserprozesse als 64-Bit und die WebView-Renderer als 64-Bit ausgeführt werden.

Bromite erstellt nur die 64-Bit-Version der APKs, daher denke ich, dass die Prozesse zumindest in diesem Aspekt nicht über 32-Bit laufen können.

Sie müssten selbst ein modernes eigenständiges Browserziel erstellen, um es ohne die TrichromeLibrary-Aufteilung zu haben. Ich bin mir nicht sicher, wie viele Änderungen es über targetSdkVersion hinaus gibt.

Es könnte ein Blutbad sein, aber ich muss es jetzt versuchen.

Die Verwendung der 64_32-Ziele ist jetzt auch der richtige Weg, um 64-Bit-Prozesse zu bevorzugen, und das ist Teil der Trichrome-Build-Infrastruktur.

Sicher, es hätte den Vorteil, sowohl für 32-Bit- als auch für 64-Bit-Architekturen kompatibel zu sein.

Modern bedeutet nicht wirklich modern - es bedeutete modern zu der Zeit, als es existierte, verglichen mit dem älteren. Es wurde durch Monochrome und dann Trichrome ersetzt.

Ja, mir war die Relativität von "modern" bewusst - aber was mich an Ihren Beiträgen überrascht ist, dass es tatsächlich einen erheblichen Unterschied in den Sicherheitsfunktionen (und möglicherweise nicht nur in Bezug auf die Sicherheit?) gibt, wenn Sie MonoChrome < Android10 und TriChrome > verwenden = Android10. Ich hatte immer den Eindruck, dass der einzige Vorteil die Shared Libraries/Speichereinsparungen in Verbindung mit einem SystemWebView waren und sonst nichts.

Möchten Sie diese Unterschiede erklären oder mich anderweitig auf eine offizielle Dokumentation hinweisen, damit ich mehr darüber erfahren kann? Ich möchte dieses Problem sicherlich angehen, sobald ich die Entität davon verstanden habe.

Wir verwenden die 64_32-Version der Targets, damit 64-Bit nicht nur unterstützt, sondern gegenüber 32-Bit auch bevorzugt wird, damit alle Browserprozesse als 64-Bit und die WebView-Renderer als 64-Bit ausgeführt werden.

Bromite erstellt nur die 64-Bit-Version der APKs, daher denke ich, dass die Prozesse zumindest in diesem Aspekt nicht über 32-Bit laufen können.

Sie müssten selbst ein modernes eigenständiges Browserziel erstellen, um es ohne die TrichromeLibrary-Aufteilung zu haben. Ich bin mir nicht sicher, wie viele Änderungen es über targetSdkVersion hinaus gibt.

Es könnte ein Blutbad sein, aber ich muss es jetzt versuchen.

Ich erinnere mich an eine Google-Gruppendiskussion über Trichrome vs. Monochrom, aber ich kann sie jetzt nicht finden

@csagan5 Solange targetSdkVersion auf den richtigen Wert gesetzt ist (29 für Android 10), ist es bei weitem kein so großes Problem wie früher und ich denke, sie haben diesen Teil jetzt wahrscheinlich für alle Ziele geändert aufgrund der Anforderungen für den Play Store.

Solange targetSdkVersion auf den richtigen Wert eingestellt ist (29 für Android 10), ist es nicht annähernd so ein großes Problem wie früher und ich denke, sie haben diesen Teil jetzt wahrscheinlich aufgrund des Play Stores für alle Ziele geändert Bedarf.

Okay, danke für deine Antwort. Ich könnte also die Verwendung von TriChrome vermeiden, indem ich ChromeModernPublic einfach mit einem anderen targetSdkVersion aufbaue. Es ist sinnvoll, dass das Nichteinbeziehen älterer Bindungen die Gefährdung durch weniger sichere APIs verringert.

targetSdkVersion sollte unabhängig von minSdkVersion immer 29 sein. Trichrome hat eine viel höhere minSdkVersion und kann es vermeiden, Legacy-Dinge einzubeziehen und Legacy-Ansätze wie den verrückten Linker zu verwenden. Ich bin mir im Moment jedoch nicht ganz sicher, wie man ein richtiges, wirklich modernes eigenständiges Browserziel einrichtet. Es gibt ein paar Dinge, die angepasst werden müssen.

@thestinger Ich habe eine Frage zu Trichrome. Die Anweisungen hier sagen, dass Trichrome zwei Dateien erzeugen wird, TrichromeChrome.aab und TrichromeLibrary.apk . Nach meinem Verständnis handelt es sich bei TrichromeLibrary.apk nur um die Bibliotheksdateien, die nicht das Hauptausführbare enthalten, und TrichromeChrome.aab ist eine Bundle-Datei, die nicht direkt auf einem Telefon wie .apk installiert werden kann. Wie installiert man also eigentlich den gesamten Browser, ohne etwas Ausgefallenes wie das Extrahieren von APK aus aab zu tun?

Sie können eine universelle APK aus dem Bundle generieren oder Sie können eine auf das Gerät spezialisierte APK generieren, auf dem Sie installieren, was der Play Store für Entwickler tut, die ihre Signaturschlüssel an Google geben. Das Tool zum Generieren von APKs (universal oder stärker auf Geräte spezialisiert) ist Open Source (Bundletool). Ich empfehle, sich generate_release.sh im Vanadium-Repository anzusehen.

@csagan5
@SebiderSushi

Ich habe ein Motorola One Power-Telefon,
NOROOT-gesperrter Bootloader.
Kein Chrom verbaut.
Nur com.google.android.webview vorinstalliert, das ich mit deinstalliert habe
adb shell pm deinstallieren --user 0 com.google.android.webview

Erfolg

Problem- Bromite installiert, aber nicht in dev.settings angezeigt

Framework-res.apk res/xml/config_webview_packages.xml

Gibt diese Ausgabe aus, dh nur eine Webansicht hat das auch ohne Signatur definiert

E: webviewproviders (Zeile=17)
E: webviewprovider (Zeile=19)
A: availableByDefault=(type 0x12)0xffffffff
A: description="Android WebView" (Roh: "Android WebView")
A: packageName="com.android.webview" (Roh: "com.android.webview")

adb shell dumpsys webviewupdate
Gibt diese Ausgabe

Aktueller Status des WebView Update Service
Fallback-Logik aktiviert: false
Multiprozess aktiviert: wahr
Aktuelles WebView-Paket (Name, Version): (com.google.android.webview, 77.0.3865.92)
Minimale targetSdk-Version: 29
Mindestens WebView-Versionscode: 386509238
Anzahl der gestarteten Relros: 2
Anzahl fertiger Rollen: 2
WebView-Paket verschmutzt: false
Jedes installierte WebView-Paket: true
Bevorzugtes WebView-Paket (Name, Version): (com.google.android.webview, 77.0.3865.92)
WebView-Pakete:
Gültiges Paket com.google.android.webview (versionName: 77.0.3865.92, versionCode: 386509238, targetSdkVersion: 29) ist für alle Benutzer installiert/aktiviert
com.google.android.webview.beta ist NICHT installiert.
com.google.android.webview.dev ist NICHT installiert.
com.google.android.webview.canary ist NICHT installiert.
com.google.android.webview.debug ist NICHT installiert.
Ungültiges Paket com.android.webview (versionName: 83.0.4103.119, versionCode: 1592784620, targetSdkVersion: 29), Grund: Falsche Signatur

Es zeigt eine falsche Signatur für Bromit und nicht für andere Webansichten wie com.google.android.webview, obwohl sie nicht in Framework-res.apk definiert ist

@csagan5
@SebiderSushi
Falsche Signatur

Es zeigt eine falsche Signatur für Bromit und nicht für andere Webansichten wie com.google.android.webview, obwohl sie nicht in Framework-res.apk definiert ist

Eigentlich habe ich das gleiche Problem mit meinem Android 10 auf Huawei p smart 2019.