Bromite: WebView كعب روتين apk لتبسيط التثبيت

أنا أفهم ما تقصده ، لكنني لن أتمكن من تطوير هذا. يمكنك البدء بتطوير شيء مثل هذا ومعرفة كيف يتم الحفاظ عليه.

يتطلب أي شيء متعلق بـ SystemWebView دعم المستخدم المستمر.

يمكنني تحضير واختبار إثبات المفهوم. ولكن في النهاية ، يجب أن يتم التوقيع عليها رسميًا للسماح بتثبيت الإصدارات الرسمية من Bromite SystemWebView كتحديثات لها.

أيضًا ، قد تكون نظرة عامة على الإمكانات الضرورية لـ WebView بصرف النظر عن الأذونات المعلنة في بيانها وتسجيلها كعرض ويب للنظام أمرًا جيدًا ، لذلك لن يفشل stub apk بطريق الخطأ في طلب كل شيء من النظام.

كانت الفكرة الأخرى التي خطرت لي هي ملء أي كائن عرض ويب قد ينشئه تطبيق آخر باستخدام ملف apk stub ، وسيتم ملؤه بمعلومات مفيدة. IE إذا تم تثبيت ملف apk فقط ، فإن فتح المتصفح المستند إلى عرض الويب الخاص بي سيملأه ببعض الإشعارات بأن Bromite WebView لم يتم تثبيته بالكامل بعد ويحتاج ببساطة إلى الترقية ليعمل. بما أنني لست على دراية كاملة بالأجزاء الداخلية لعرض ويب android ، فليس لدي أدنى فكرة عن كيفية تحقيق ذلك.

بالنسبة للصيانة ، أعتقد أنه قد يكون من غير الضروري نشر ملف apk لهذا أكثر من مرة. طالما أن اسم الحزمة والتوقيع لا يغيران ملف apk ، فلا داعي لتغييره. (وطالما أنه لا توجد تغييرات في أي أذونات أو امتيازات لا يمكن الإعلان عنها إلا في ملف apk الأصلي - لكنني أشك في وجودها حتى في نظام Android)

حسنًا ، لقد تمكنت للتو من الحصول على عمل أساسي فائق لإثبات المفهوم من خلال القيام بما يلي:

• أنشئ مشروع Android Studio جديدًا بدون نشاط من القالب
• قم بإزالة أيقونات التطبيق التي تم إنشاؤها والسمات والتبعيات من البرنامج النصي gradle
• بناء وتوقيع هذا الشيء
• قم بتنزيل إصدار رسمي لـ Bromite System WebView واستقال من ذلك بنفس المفتاح
• ضع stub apk في / system / app / webview / على جهاز android Pie وأعد التشغيل
  في هذه المرحلة ، لم يتم إدراج موفر عرض ويب في إعدادات التطوير ، ولكن تم تثبيت بنية عرض الويب بروميت المستقيلة وبعد ذلك تم تطبيق Bromite System WebView في قائمة WebView في إعدادات التطوير واستخدام Webviews كان ممكنًا.

الآن يجب التأكد من عدم التغاضي عن أي شيء هنا وأن المفهوم قابل للتطبيق على نظام Android 10 وما بعده أيضًا (قصة التراكب). ولكن بصرف النظر عن جعلها تعمل بمجرد أن لا أرى أي عبء صيانة متوقع هنا.

نسخة من الكود المصدري الذي استخدمته في أبتر apk الاختباري:
https://github.com/SebiderSushi/WebViewStub-ProofOfConcept
(لكن الأشياء الوحيدة التي حددتها على أنها مهمة حتى الآن هي اسم الحزمة والتوقيع.)

حسنًا ، لقد اختبرت هذا للتو على جهاز يعمل بنظام Lineage 17.1 وقد نجح أيضًا.
ما فعلته هو تغيير Magisk Installer بواسطة linuxandria بحيث يضع ملف apk الخاص بي بدلاً من تنزيل الملف الرسمي.
يعتني المثبت بمشكلة التراكب مع android 10+.

الكل في كل شيء سار على ما يرام تمامًا كما هو الحال مع جهاز Pie - لم يظهر كعب الروتين في قائمة موفري WevView ، ولكن بمجرد تثبيت WebView APK الكامل المعاد توقيعه ، ظهر في القائمة ويمكن أن يكون التي تستخدمها التطبيقات.

الآن يجب التأكد من عدم التغاضي عن أي شيء هنا وأن المفهوم قابل للتطبيق على نظام Android 10 وما بعده أيضًا (قصة التراكب).

يمكن اختباره على العديد من إصدارات Android باستخدام أجهزة Android الافتراضية.

لكن الأشياء الوحيدة التي حددتها على أنها بالغة الأهمية حتى الآن هي اسم الحزمة والتوقيع.

في الواقع ، هذا ما يسمح بتثبيت حزمة أخرى بنفس الاسم والتوقيع. يجب أن يكون رمز إصدار كعب الروتين أصغر أيضًا.

SebiderSushi بخصوص اسم الحزمة: يمكننا أيضًا استخدام اسم حزمة خاص بالبروميت ، لكنني لست متأكدًا من الكسر الذي قد يكون متضمنًا. إذا استبعدنا المستخدمين الذين لديهم محمل إقلاع غير مؤمن يمكنه استخدام أي اسم حزمة إلى حد كبير ، فما هي حالات الاستخدام المتبقية حيث يكون الاحتفاظ بـ com.android.webview (كما هو الحال حاليًا) مفيدًا؟ هل تعرف ما يفعله مطورو الويب الآخرون حيال ذلك؟

راجع أيضًا: https://github.com/bromite/bromite/wiki/Installing-SystemWebView#about -the-package-name

آسف لترك هذه القضية تنزلق لفترة طويلة.
لقد لاحظت مؤخرًا أنني لا أمتلك أي إعداد (جهاز أو ذاكرة تخزين فقط أو ذاكرة قراءة فقط مخصصة) حيث توجد أي تعقيدات في تثبيت Bromite WebView. وهذا يعني أنني كنت قادرًا على تثبيت واستخدام Bromite WebView كتطبيق مستخدم في جميع إعداداتي ببساطة عن طريق إزالة ملف apk com.android.webview المثبت مسبقًا من صورة النظام.
(تشير "جميع الإعدادات" إلى كل ما يُدرج في القائمة البيضاء com.android.weview كموفر عرض ويب للبدء به)

تمكنت من إعادة إنتاج هذا في AVD يعمل بنظام Android Pie أيضًا.

لذلك أدركت بشكل أساسي أنني لا أمتلك في الواقع حالة استخدام لهذا ، ولا يمكنني تقديم أي موارد اختبار تشبه أي موقف حرج حيث يكون التثبيت في قسم النظام إلزاميًا.

بخلاف ذلك ، للرجوع إلى سؤالك:
نظرًا لحقيقة أن مزودي System WebView يجب أن يكونوا مدرجين في القائمة البيضاء بشكل صريح في إطار النظام ، فإن اختيار اسم حزمة معين من bromite سيكون مفيدًا لأي شخص قادر على تصحيح إطار عمل نظامهم لإدراج هذا الاسم في القائمة البيضاء. بخلاف ذلك ، فإنه يدعم في الغالب حالات الاستخدام التي يكون فيها الاحتفاظ بإصدار النظام com.android.webview مثبتًا أمرًا مطلوبًا.

الشيء الذي يحمل اسم الحزمة com.android.webview هو أن هناك العديد من ROMs الموجودة والتي تسرد اسم الحزمة هذا كمزود لعرض الويب دون الحاجة أيضًا إلى توقيعها بواسطة مفتاح خاص كما هو الحال مع Google Chrome أو أشياء مماثلة. هذا هو السبب في أن استخدام اسم الحزمة هذا هو أسهل شيء للأشخاص الذين يستخدمون محمل الإقلاع غير المؤمّن أيضًا.
ولكن كما هو الحال الآن (مع AVB والأشياء) ، من المستحيل في الغالب استخدام تطبيق WebView المخصص على الإطلاق بدون أداة تحميل التشغيل غير المؤمّنة وأشياء مثل Magisk أو الوصول إلى قسم النظام ، نظرًا لوجود حزمة مثبتة مسبقًا في النظام لأي مزود عرض ويب النظام المدرج في القائمة البيضاء.

ربما شاهدت IIRC com.google.android.webview مدرجًا في القائمة البيضاء بدون تثبيت توقيع في ذاكرة تخزين واحدة معينة ، لكن لا يمكنني تخيل كيف يمكن أن يتفاعل Google مع استخدام اسم الحزمة الخاص بهم.

إن إعطاء البروميت اسم حزمة فريد سيكون هو الشيء الصحيح تقنيًا الذي يجب القيام به ، ولكن لسوء الحظ لا يعمل إلا إذا كان بإمكان المستخدمين تصحيح ملف res.apk الخاص بهم أو إذا تم تجميع WebView بواسطة مشرف ROM أو المطور.

ربما شاهدت IIRC com.google.android.webview مدرجًا في القائمة البيضاء بدون تثبيت توقيع في ذاكرة تخزين واحدة معينة ، لكن لا يمكنني تخيل كيف يمكن أن يتفاعل Google مع استخدام اسم الحزمة الخاص بهم.

لا توجد ميزة لمبادلة com.android.webview بـ com.google.android.webview ، ولكن في أي مكان تراهم فيه بدون تثبيت التوقيع ، فهذا خطأ أمني خطير.
لن يهتموا بهذا لأن الأصالة مضمونة بالتوقيع وليس اسم الحزمة (انظر الاقتباس في https://github.com/bromite/bromite/wiki/Installing-SystemWebView#installation-without-root) ، ولكن كـ قلت إنه لا يوجد حافز لاستخدام اسم حزمة مختلف نظرًا لأنه سيعمل فقط على التركيبات "ذات الأبواب الخلفية". وإذا أضفت بابًا خلفيًا يدويًا ، فيمكنك أيضًا إضافة اسم حزمة خاص بالبروميت مع التوقيع الصحيح.

سيكون إعطاء Bromite اسم حزمة فريدًا هو الشيء الصحيح تقنيًا الذي يجب القيام به ، ولكن للأسف لا يعمل إلا إذا كان بإمكان المستخدمين تصحيح ملف res.apk الخاص بهم أو إذا تم تجميع WebView بواسطة مشرف ROM أو المطور.

إذا كان الجذر ضروريًا لأي إجراء تثبيت SystemWebView ، فيمكننا استخدام اسم حزمة خاص بـ Bromite. تذكر صفحة الويكي النهج المنقح ولكن ليس لدي دليل على نجاحه. من شأنه أن يتعارض مع ضمانات النموذج الأمني. ربما يمكنك القيام ببعض البحث هناك؟

لا يمكن أن تعمل هذه الأساليب إلا إذا لم يكن Android SystemWebView موجودًا ، نظرًا لأن Bromite SystemWebView يستخدم نفس اسم الحزمة وسيفشل التحقق من توقيع APK بخلاف ذلك.

بقدر ما أفهمها ، فإن صفحة wiki تدرك آثار نموذج الأمان ، كما أن أسلوب debloater مخصص للإصدارات السابقة لنظام Android 7.0 ، حيث لم تكن هناك طريقة لاختيار تطبيق WebView يدويًا في إعدادات المطور. لهذا السبب ، يلزم تعطيل أي من موفري WebView الآخرين ذوي الأولوية الأعلى من com.android.webview لإجبار النظام على الرجوع إلى com.android.webview .

SebiderSushi ما الذي يجب القيام به هنا؟ بقدر ما أعرف لا أحد يعمل على هذا.

لست متأكدًا مما تقصده.

بقدر ما يتعلق الأمر بـ WebView stub apk ، يجب القيام بما يلي (حسب معرفتي الحالية):

قم بتجميع ملف apk الذي يحتوي بشكل أساسي على بيان باسم الحزمة الصحيح. يمكن العثور على دليل مرجعي للمفهوم هنا .

يحتاج ملف apk هذا فقط إلى التوقيع بنفس التوقيع مثل تطبيقات إصدار BromiteWebView ويتم كل شيء حتى يتم الكشف عن المزيد من المشكلات.

إنه أكثر تعقيدًا من ذلك بقليل:

• يجب إنشاء SystemWebView باسم الحزمة الحالية com.android.webview
• يجب أن يتم بناؤه أيضًا باسم حزمة جديد
• يجب بناء كعب

لا يمكنني الاحتفاظ بـ com.android.webview إلى الأبد ، لكن في نفس الوقت ما زلت غير متأكد من الحالات التي من المهم الاحتفاظ بها باسم الحزمة.

بالتأكيد. كنت أشير فقط إلى كعب عرض الويب ، حيث أرى السؤال حول اسم الحزمة كموضوع مختلف. بخصوص ذلك ، هل ألقيت نظرة على النظرة العامة التي ربطتها في تعليقي السابق على المسألة الأخرى؟ لقد جمعت فقرة حول اسم الحزمة وحول جميع الاعتبارات المحتملة التي أراها هناك ، واستنتاجي هو الاحتفاظ بـ com.android.webview .

كما هو الحال حاليًا ، أعتقد أن الفوائد المفقودة لاستخدام com.android.webview أو تكلفة الإنشاء باستخدام اسمين للحزم تفوق الفوائد المكتسبة من اسم الحزمة الفريد.

بالطبع يمكن إعادة النظر في هذه النقطة إذا كان الفريق الذي يقف وراء ذاكرة القراءة فقط المخصصة الموزعة على نطاق واسع (مثل LineageOS) سيكون على استعداد لإدراج اسم حزمة فريد من نوعه لبرنامج Bromite WebView في القائمة البيضاء.
أعتقد أننا يمكن أن نتفق جميعًا على أنه لا أحد يتوقع أن تقوم Google أو بعض مصنعي المعدات الأصلية بإضافة Bromite إلى القائمة البيضاء في AOSP أو فرعهم من Android.

قد يتم إدراج com.android.webview القائمة البيضاء على مجموعة من ROM هناك ، ولكن بالتأكيد هل تم إدراجه في القائمة البيضاء بدون توقيع في LineageOS وأيضًا AOSP خالص com.android.webview مع بنياتهم.

هذا يجعل الكثير من ROM حيث تكون وحدة Magisk التي تحتوي فقط على الملفات system/app/webview/BromiteWebViewStub.apk و system/app/webview/replace كافية للسماح بالتثبيت.
سيكون البديل بدون magisk هو cat BromiteWebViewStub.apk > /system/app/webview/webview.apk أو ما يعادله.

وفي تصميمات userdebug (جميع إصدارات LineageOS الرسمية!) ، لا توجد حاجة حتى إلى ملف apk كعب روتين ، كما أن rm -fr /system/app/webview كافٍ للسماح بالتثبيت.

النقطة المهمة: كل هذا ينطبق على إصدارات Android الأقدم دون دعم RRO أيضًا.
الحالات التي تركها هذا هي الأجهزة التي لا تُدرج في القائمة البيضاء com.android.webview والتي تحتاج إلى RRO إذا كان ذلك ممكنًا للوصول إلى أي مكان.

من الجدير بالذكر أن بعض المقاييس حول هذا ستكون أجمل من كل افتراضاتي. بيانات العالم الحقيقي حول عدد ROM التي تقع في أي من الفئات المذكورة أعلاه.

هل تم إدراجه في القائمة البيضاء بدون توقيع في LineageOS وأيضًا AOSP الخالص

أليست هذه ثغرة أمنية؟ قد أفهم حالة AOSP ، حيث من المفترض أن يقوم مصنعي المعدات الأصلية "بإكمالها" قبل الإصدار ، ولكن كيف يمكن إطلاق إصدارات LineageOS مع فتح هذه المشكلة؟

وعلى بنيات userdebug (جميع إصدارات LineageOS الرسمية!)

حسنًا ، ربما لا أفهم كيف يتم تقويتها للاستخدام. مرجعي لنظام التشغيل Android الآمن غير المخزن هو GrapheneOS .

كما هو الحال حاليًا ، أعتقد أن الفوائد المفقودة من استخدام com.android.webview أو تكلفة الإنشاء باستخدام اسمين للحزم تفوق الفوائد المكتسبة من اسم الحزمة الفريد.

بالطبع يمكن إعادة النظر في هذه النقطة إذا كان الفريق الذي يقف وراء ذاكرة القراءة فقط المخصصة الموزعة على نطاق واسع (مثل LineageOS) سيكون على استعداد لإدراج اسم حزمة فريد من نوعه لبرنامج Bromite WebView في القائمة البيضاء.

المشروع ليس له - ولا يسعى - الانتماء؛ يجب أن أتخذ قرارًا بغض النظر عما يقرره مشروع آخر شعبي - لكن منفصل -.

دعنا نضع الأمر بطريقة أخرى: إذا كان اسم الحزمة org.bromite.webview ، فما هي المشكلات لاستخدامه على LineageOS أو ما شابه؟ لا أعتقد أن هناك ما يدعو للقلق: إنهم يعملون بالفعل بأذونات مفتوحة على مصراعيها ، ويبدو أن فقرتك حول اسم الحزمة تؤكد ذلك.

القضايا المتبقية الوحيدة هي:

1. الإزعاج من تغيير اسم الحزمة للمستخدمين الحاليين
2. قد تحتوي بعض ذاكرة القراءة فقط على قائمة بيضاء غير مثبتة com.android.webview ، وستفقد القدرة على تثبيت عرض الويب

(1) سيكون هناك دائمًا ، ليس من تلقاء نفسه سببًا وجيهًا لعدم إجراء أي تغيير / تقدم
ليس لدي دليل على (2) ولا أرقام كما قلت.

هل ألقيت نظرة على النظرة العامة التي ربطتها في تعليقي السابق على المسألة الأخرى؟

نعم ، لكني توصلت إلى استنتاجات مختلفة: يجب أن يكون المستخدم قادرًا على اختيار عرض الويب دون إعادة التشغيل في مدير التمهيد أو تعديل ROM ، وإعادة استخدام أسماء الحزم غير صحيحة من منظور كيفية عمل Android.

مرة أخرى ، وفقًا للأمان ، لا أرى المشكلة.
وفقًا لتعليق مطور Chromium المذكور في دليل تثبيت موقع wiki الأصلي والذي أعيد الاستشهاد به في الصفحة الرئيسية الخاصة بي:

يتميز WebView بامتيازات كبيرة لأنه يتم تحميله في مساحة عناوين التطبيقات الأخرى ، وبالتالي يمكنه الوصول إلى البيانات والأذونات الخاصة بكل تطبيق يستخدمه - وبالتالي ، لا يمكن استبداله إلا بشخص لديه بالفعل القدرة على اختراق التطبيق وضع الحماية على أي حال: شخص لديه حق الوصول إلى الجذر ، أو منشئ صورة النظام.

على هذا النحو ، أرى أنه من الكافي "سد فجوة الأمان" من خلال تقديم إما إنشاءات "المستخدم" أو عن طريق التثبيت المسبق لحزمة تملأ المكان. نظرًا لأن أي شخص لا يزال بإمكانه استبدال WebView سيظل بحاجة إلى الوصول إلى الجذر ، فهو موجود بالفعل. لا ترى كيف تزداد الأمور سوءًا بالنسبة للضحية إذا تمكن المهاجم أيضًا من استبدال عرض الويب على رأس الوصول الكامل على الأقل إلى قسم النظام.

وحول نظام الجرافين: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
إما أنهم لا يرون هذا مختلفًا أو يستبدلون هذا التكوين بواحد صارم في وقت الإنشاء. نعم ، ربما يقومون بشحن user build لكن هذا يعني فقط أن المهاجم سيضطر فقط إلى وضع WebView الضار في قسم النظام.

أيضًا ، نظرًا لأن GrapheneOS أو أي ذاكرة ROM حالية أخرى ستعمل على الأقل على android Pie ، فإن المهاجم الذي لديه حق الوصول إلى الجذر سيكون قادرًا أيضًا على وضع وتسجيل RRO واستبدال قائمة WebView البيضاء بأي شيء يريده.
(هذا ، وفقًا للاختبار الذي أجريته ، تمكنت من تسجيل RRO على Pie and Ten ، ولكن ليس على Oreo أو أقل. أنا في بداية التعرف على RROs على الرغم من ذلك ، ولكن النقطة بالتأكيد تعني android Ten. )

هاه. حسنًا ، سأخوض في التفاصيل حول نقاطك الآن وبعد ذلك ربما يمكنك الإشارة إلى كيف يمكن فهم توضيحي على الويكي بطريقة أخرى أو أن يكون غير واضح بشأن جوانب معينة.
هناك شيء واحد أراه بالفعل وهو أنني لم أغطي منظمات RROs هناك إلا بشكل غامض: هذا يرجع إلى افتقاري إلى معرفتي بها.

أوافق: استخدام اسم حزمة فريد هو الشيء الصحيح الذي يجب القيام به. تعد القدرة على اختيار تطبيق WebView في مساحة المستخدمين أمرًا مناسبًا وقد تتطلب بعض حالات الاستخدام ذلك (على الرغم من أنني لا أعرف أيًا منها).

أعتقد أن إعادة استخدام com.android.webview هو حل وسط صالح ، لأنني لا أرى حالات الاستخدام التي تتطلب تبديل التنفيذ باستمرار ولكن بدلاً من ذلك حيث يريد المستخدم ببساطة استخدام WebView مختلف كسائق يومي.
ثم مرة أخرى ، يمكن أن يحدث الخيار الأمثل ، أي أن يكون المستخدم قادرًا على تثبيت Bromite WebView كتطبيق مستخدم تمامًا مثل Google WebView واستخدامه دون لمس نظامه ، يمكن أن يحدث بشكل حصري إذا كانت مجموعة واسعة من ROMs المدرجة في القائمة البيضاء Bromite WebView من تلقاء نفسها.
نظرًا لأنه لا يمكننا توقع ذلك أبدًا ، أعتقد أنه سيكون من المنطقي الذهاب إلى حل وسط ، كما هو موضح أدناه.

تذكير: الاعتبارات التالية غير صالحة عند وجود دعم RRO. وهذا يعني أنه إذا تم إهمال إصدارات Android الأقدم ، فيجب بالتأكيد استخدام اسم حزمة فريد. في هذا الوقت ، لست متأكدًا من إصدارات Android التي يمكن تشغيل RRO فيها ، ولكن أثناء اختباراتي مع Marshmallow و Nougat و Oreo و Pie و Ten لم أتمكن إلا من تسجيل RRO على Pie وما فوق. أتذكر أن linuxandria statet RROs يمكن نظريًا جعلها متوافقة مع إصدارات أندرويد منخفضة تصل إلى 5.1 ، لذلك سنرى إلى أي مدى قد نحققه مع هذا.
ولكن بالتالي ، من الآن فصاعدًا ، سيأتي حتماً إلى اليوم الذي سيتم فيه إهمال استخدام com.android.webview .

الآن ، طالما أن إصدارات Android التي لا يمكننا تجاوز قائمة WebView البيضاء بنجاح يجب أن تدعمها Bromite WebView ، فإن الاعتبار التالي ينطبق:

بدون قائمة WebView البيضاء المخصصة ، فإن الأمل الوحيد لدعم أي جهاز هو استخدام اسم الحزمة com.android.webview ، حيث يتم إدراجه في كثير من الأحيان في القائمة البيضاء دون تثبيت توقيع.

لن يعمل استخدام اسم حزمة آخر ، ولا حتى على LineageOS. لقد قاموا فقط بإدراج Google WebView وحفنة من متغيرات Google Chrome في com.android.webview بدون تثبيت توقيع.
الباب الوحيد المفتوح مع LineageOS فيما يتعلق بـ WebView هو أنهم يشحنون userdebug builds ، مما يسمح بتثبيت WebView بعد إزالة الحزمة الأصلية فقط من النظام بدلاً من وضع كعب أو الحزمة المخصصة في النظام تقسيم. وهذا ، مرة أخرى ، ليس بالأمر المهم إذا كنت بالفعل في وضع يسمح لك بإزالة عرض الويب الأصلي. لا يتطلب الأمر سوى بذل المزيد من الجهد للقيام بذلك كمستخدم أو كمهاجم.

السبب الذي يجعلني أتحدث باستمرار عن LineageOS

هذه الأرقام: https://www.lineageoslog.com/statistics

أعتقد أن ROMs المخصصة المستندة إلى LineageOS و LineageOS "ربما تكون جزءًا مهمًا من قاعدة مستخدم Bromite WebView". (بالطبع ، من المحتمل أن تكون مشاريع أخرى مثل OmniROM قابلة للاستخدام مع عروض الويب المخصصة أيضًا.)

أفعل هذا بسبب الاعتبارات التالية:

• لتثبيت أي شيء مخصص هذه الأيام ، ستحتاج إلى أداة تحميل إقلاع غير مؤمنة. سيتم أيضًا إلغاء قفل الأجهزة التي تعمل بنظام ROM المخصص.
• قد يكون المستخدمون الذين يرغبون في العبث بأجهزتهم وتخصيصها أكثر عرضة لاستخدام ذاكرة القراءة فقط المخصصة أيضًا

• وبالطبع ، إنها حالة استخدامي الشخصي.

من الواضح أن أي مقاييس مستخدم فعلية لـ Bromite WebView نفسها ستكون لطيفة. طالما أننا لا نستطيع الوصول إلى هؤلاء ، فأنا أرى فقط أنه يمكننا إجراء تكهنات أو قلب عملة معدنية أو إهمال أي شيء لا يمكننا تشغيل RRO عليه.
في هذه الملاحظة: تقوم Easy xkcd على سبيل المثال بإجراء استبيانات للمستخدمين من وقت لآخر عبر مستندات google. للأسف ، بدون واجهة مستخدم ، سيكون من الصعب التقاط جزء كبير من المستخدمين على ما أعتقد.

TL ؛ DR:

إن اعتباري current هو "القدرة على تبديل عرض الويب في مساحة المستخدمين" مقابل "الأجهزة مع عدم وجود طريقة أخرى لتثبيت عرض ويب مخصص من خلال استبدال com.android.webview ".

خاصة وأنني لا أرى حالات استخدام تتطلب الأولى ، فأنا مقتنع بأن الجانب الأخير يزن أكثر من ذلك بكثير.

يتلخص السؤال في:
هل هناك جزء كبير من الأجهزة التي تشغل Bromite WebView حيث لا يوجد لدينا خيار لتجاوز القائمة البيضاء WebView؟

ومرة أخرى ، يعتمد ما قلته على معرفتنا الحالية حول استبدال القائمة البيضاء لـ WebView. إذا كان أي شخص يبحث عن طرق جديدة وأفضل لاستبدال القائمة البيضاء على أجهزة العالم الحقيقي ، فسوف يتحول الجدل بأكمله نحو اسم حزمة فريد.

أي إعداد حيث يمكن تجاوز القائمة البيضاء يمكن دعمه بشكل صحيح بواسطة Bromite WebView.

على هذا النحو ، أرى أنه من الكافي "سد فجوة الأمان" من خلال تقديم إما إنشاءات "المستخدم" أو عن طريق التثبيت المسبق لحزمة تملأ المكان. نظرًا لأن أي شخص لا يزال بإمكانه استبدال WebView ، فسيظل بحاجة إلى الوصول إلى الجذر

اعتقدت أنك لست بحاجة إلى الوصول إلى الجذر إذا كانت الحزمة موجودة وبدون توقيع.

وحول نظام الجرافين: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
إما أنهم لا يرون هذا مختلفًا أو يستبدلون هذا التكوين بواحد صارم في وقت الإنشاء. نعم ، ربما يقومون بشحن user build لكن هذا يعني فقط أن المهاجم سيضطر فقط إلى وضع WebView الضار في قسم النظام.

دعنا نسأل thestinger : لا توجد إمكانية لتثبيت عرض ويب ضار (يطابق اسم الحزمة المدرجة في القائمة البيضاء) على GrapheneOS دون الوصول إلى الجذر ، أليس كذلك؟

بدون قائمة WebView البيضاء المخصصة ، فإن الأمل الوحيد لدعم أي جهاز هو استخدام اسم الحزمة com.android.webview ، حيث يتم إدراجه في كثير من الأحيان في القائمة البيضاء دون تثبيت توقيع.

لقد نسيت أن تذكر أنه يجب على المستخدم أيضًا الوصول إلى الجذر . ماذا عن تعديل نظام التشغيل من خلال framework-res.apk للسماح بعروض ويب أخرى؟ هل يمكن أن يتم ذلك بالجذر وحده (لا أعتقد ذلك)؟ يمكن أن يتم ذلك دائمًا باستخدام وصول الاسترداد ، أليس كذلك؟

إذا كان أي شخص يبحث عن طرق جديدة وأفضل لاستبدال القائمة البيضاء على أجهزة العالم الحقيقي ، فسوف يتحول الجدل بأكمله نحو اسم حزمة فريد.

أعتقد أنه من الممكن تعديل أي ROM لدعم عروض الويب الأخرى من خلال أداة تحميل التشغيل المخصصة ؛ انظر https://forum.xda-developers.com/showpost.

هذه الأرقام: https://www.lineageoslog.com/statistics

عذرًا ، لا ينتمي Bromite إلى LineageOS.

• وبالطبع ، إنها حالة استخدامي الشخصي.

هذا يجعلك متحيزا. شهرة لفضح التحيز ، ولكن لا يزال يتعين علي الاختيار بناءً على الحالة المحايدة ، على سبيل المثال ، أي مستخدم يستخدم أي ذاكرة قراءة فقط.

دعنا نسأل thestinger : لا توجد إمكانية لتثبيت عرض ويب ضار (يطابق اسم الحزمة المدرجة في القائمة البيضاء) على GrapheneOS دون الوصول إلى الجذر ، أليس كذلك؟

صحيح ، ويستخدم التمهيد المتحقق منه. يتم التحقق من نظام التشغيل من جذر الثقة.

وحول نظام الجرافين: https://github.com/GrapheneOS/platform_frameworks_base/blob/10/core/res/res/xml/config_webview_packages.xml
إما أنهم لا يرون هذا مختلفًا أو يستبدلون هذا التكوين بواحد صارم في وقت الإنشاء. نعم ، من المحتمل أنهم يشحنون بناء المستخدم ولكن هذا يعني فقط أن المهاجم سيضطر فقط إلى وضع WebView الضار في قسم النظام.

أيضًا ، نظرًا لأن GrapheneOS أو أي ذاكرة ROM حالية أخرى ستعمل على الأقل على android Pie ، فإن المهاجم الذي لديه حق الوصول إلى الجذر سيكون قادرًا أيضًا على وضع وتسجيل RRO واستبدال قائمة WebView البيضاء بأي شيء يريده.
(هذا ، وفقًا للاختبار الذي أجريته ، تمكنت من تسجيل RRO على Pie and Ten ، ولكن ليس على Oreo أو أقل. أنا في بداية التعرف على RROs على الرغم من ذلك ، ولكن النقطة بالتأكيد تعني android Ten. )

هذا غير منطقي. كيف بالضبط سيساعد فحص التوقيع الزائد في أي موقف؟ إذا استغل أحد المهاجمين نظام التشغيل بنجاح للحصول على حق الوصول الكامل إلى الجذر ، فما فائدة الحصول على توقيع ثابت هنا؟ أيضًا ، أنت تفهم أن GrapheneOS لديها تمهيد كامل تم التحقق منه تمامًا مثل نظام تشغيل الأسهم ، أليس كذلك؟ إنه ليس ذا صلة خاصة بهذا على الرغم من ...

يستخدم Android تثبيت المفاتيح لكل تثبيت تطبيق فردي. إذا تم تضمين أحد التطبيقات في صورة النظام ، فسيتم تثبيت المفتاح بشكل دائم عبر التطبيق المدمج في صورة النظام. ليس من المنطقي التحدث عن هجوم حيث يتم استبدال التطبيق في صورة النظام. سيحتاج المهاجم بالفعل إلى الحصول على حق الوصول الكامل إلى الجذر لإعادة التحميل على أنه قابل للكتابة وتعديله. يمكنهم أيضًا تعديل القائمة البيضاء ... كيف يكون من المنطقي اقتراح ذلك كناقل للهجوم؟ أيضًا ، سيتم اكتشافه على أنه تلاعب من خلال التحقق منه في التمهيد التالي في كلتا الحالتين. تثق سلاسل التمهيد التي تم التحقق منها من البرنامج الثابت وتتحقق من جميع صور نظام التشغيل.

تحديد التوقيع config_webview_packages.xml للحالات التي لا يكون فيها التطبيق مجمّعًا في نظام التشغيل. إما أن تقوم بإدراج أحد التطبيقات المجمعة في نظام التشغيل دون تحديد دبوس مفتاح أو إدراج تطبيق غير مضمن في نظام التشغيل باستخدام دبوس مفتاح. يعد إدراج دبوس المفتاح طريقة للحفاظ على الأمان على الرغم من عدم تضمينه في نظام التشغيل. إنها ليست الطريقة العادية لاستخدام هذا التكوين. سيكون الأمر معقدًا بلا داعٍ أن يحتاج الجميع إلى تعديل ملف التكوين هذا لتحديد مفتاح WebView المجمّع وليس كيفية تنفيذه. يوفر نظام التشغيل التحقق من صحة التوقيع لكل حزمة مثبتة بالفعل.

لا أستطيع التفكير في أي حالة يكون فيها استخدام com.android.webview مفيدًا. إذا كان هناك تطبيق مجمع بالفعل ، فلا يمكنك تثبيته. إذا لم يكن هناك واحد مثبت ، فيجب أن تحتوي القائمة البيضاء على مفتاح مثبت. في كلتا الحالتين ، تحتاج إلى دعم Bromite المدمج في نظام التشغيل. يتطلب القيام بذلك بشكل صحيح مع نموذج الأمان ونظام التحديث المحفوظ القيام بذلك كجزء من البناء قبل إنشاء إصدار موقع. لا يغير اختراقه في إصدار حالي عن طريق التخلي عن توافق نظام التشغيل والتحديث الذي تم التحقق منه (إذا أجريت أي تغييرات ، لقد كسرت التحديثات المتزايدة) أي شيء حقًا. يمكنك تحويل الموارد إلى xml من binary xml وتعديلها وتحويلها مرة أخرى. في كلتا الحالتين تقوم ببنائه في نظام التشغيل.

إما أن تقوم بإدراج أحد التطبيقات المجمعة في نظام التشغيل دون تحديد دبوس مفتاح أو إدراج تطبيق غير مضمن في نظام التشغيل باستخدام دبوس مفتاح.

لا أستطيع التفكير في أي حالة يكون فيها استخدام com.android.webview مفيدًا. إذا كان هناك تطبيق مجمع بالفعل ، فلا يمكنك تثبيته.

السيناريو الوحيد غير الآمن هو عندما تكون هناك حزم مدرجة في القائمة البيضاء وتأتي ذاكرة القراءة فقط بدون تثبيت مثل هذه الحزم. المناقشات السابقة هنا حول هذه المسألة محيرة عندما لا يذكرون هذا الشرط صراحة.

هناك الكثير من الفرضيات هنا. الأساس المنطقي الخاص بي هو أكثر أو أقل: إذا كان com.android.webview مفيدًا للمستخدمين غير الجذر لمثل هذه الأقراص المدمجة غير الآمنة ، فليس لدي اهتمام بدعمهم.

لذا ، أعتقد أن SebiderSushi يمكن تقسيم البحث إلى قسمين:

1. خيارات لتثبيت WebView بدون جذر ومحمل إقلاع غير مؤمن (على سبيل المثال ، عملية تمهيد غير مؤكدة)
2. خيارات لتثبيت WebView مع الجذر

لقد قمت بالفعل بالكثير من التحقيقات ، ما قد يكون منطقيًا بالنسبة لي هو ترتيب هذا في نوع من دليل المستخدم / مخطط التدفق ؛ يجب أن تكون كل خطوة واضحة أيضًا بشأن التداعيات الأمنية.

أدرك أن الطريقة الوحيدة لتثبيت عرض ويب دون كسر نموذج الأمان هو دعمه في وقت الإنشاء.

وبالتالي ، فإنني أشير إلى محمل الإقلاع غير المؤمّن (وبالتالي الوصول إلى الجذر / النظام الكامل) في جميع الأوقات لأنه الطريقة الواقعية الوحيدة لتثبيت عرض ويب مخصص على جهاز المستخدم النهائي دون إنشاء ذاكرة قراءة فقط كاملة لتحقيق ذلك.

نتيجة لذلك ، لا أتحدث عن أي حالات استخدام تحافظ على AVB.

لست على دراية بأي ذاكرة ROM من شأنها أن تجمع دعم Bromite. هذا ما قصدته عندما كنت أقول

بالطبع يمكن إعادة النظر في هذه النقطة إذا كان الفريق الذي يقف وراء ذاكرة القراءة فقط المخصصة الموزعة على نطاق واسع (مثل LineageOS) سيكون على استعداد لإدراج اسم حزمة فريد من نوعه لبرنامج Bromite WebView في القائمة البيضاء.

لم أرغب في أي وقت في الإشارة إلى أي انتماء ولكن بدون حدوث مثل هذا الشيء ، فإن حالة الاستخدام الوحيدة المتبقية هي المستخدمين الذين لديهم محمل إقلاع غير مؤمن يقومون بتصحيح أقسام نظامهم أو تثبيت وحدات Magisk أو أيًا كان ما تقوم به المهمة.

لا أستطيع التفكير في أي حالة يكون فيها استخدام com.android.webview مفيدًا. [...] يمكنك تحويل الموارد إلى xml من ثنائي xml وتعديلها وتحويلها مرة أخرى. في كلتا الحالتين تقوم ببنائه في نظام التشغيل.

مكافحة المثال:

• محمل الإقلاع
• بناء المستخدم الذي يقوم بإدراج com.android.webview القائمة البيضاء بدون تثبيت توقيع
• عرض الويب المثبت مسبقًا مثبت كـ /system/app/webview/webview.apk
• لا يوجد دعم RRO (android 6 أو شيء ما)

يمكنني تثبيت Bromite WebView عن طريق التشغيل
على سبيل المثال ، cat bromitewebview.apk > /system/app/webview/webview.apk في TWRP.
ويمكنني تشغيل هذا واستخدام Bromite WebView.
فقط لأن Bromite WebView يستخدم حاليًا com.android.webview

كيف يمكنني استبدال القائمة البيضاء لعرض الويب في هذا السيناريو لدعم اسم حزمة فريد إذا لم يعمل الترقيع framework-res.apk لأنني لا أستطيع إعادة تسجيله باستخدام مفتاح النظام الأساسي؟

دعنا نسأل thestinger : لا توجد إمكانية لتثبيت عرض ويب ضار (يطابق اسم الحزمة المدرجة في القائمة البيضاء) على GrapheneOS دون الوصول إلى الجذر ، أليس كذلك؟

ينطبق هذا أيضًا على LineageOS ، حتى لو لم يدعموا AVB.

كيف يمكنني استبدال القائمة البيضاء لعرض الويب في هذا السيناريو لدعم اسم حزمة فريد إذا لم يعمل تصحيح framework-res.apk لأنني لا أستطيع إعادة تسجيله باستخدام مفتاح النظام الأساسي؟

إذا كان هذا البيان غير صحيح ثم yay.
لأنه إذا كان من الممكن تطبيق قائمة بيضاء مخصصة على أي إصدار android مدعوم من Bromite WebView ، فأنا أرى أنه خيار واضح لاسم حزمة فريد.

لكن مرة أخرى ، هذا ما كنت أقوله طوال الوقت.

كيف بالضبط سيساعد فحص التوقيع الزائد في أي موقف؟ إذا استغل أحد المهاجمين نظام التشغيل بنجاح للحصول على حق الوصول الكامل إلى الجذر ، فما فائدة الحصول على توقيع ثابت هنا؟

هذه في الواقع وجهة نظري أيضًا وما أردت أن أقوله لـ @ csagan5 بسبب هذا:

هل تم إدراجه في القائمة البيضاء بدون توقيع في LineageOS وأيضًا AOSP الخالص

أليست هذه ثغرة أمنية؟ قد أفهم حالة AOSP ، حيث من المفترض أن يقوم مصنعي المعدات الأصلية "بإكمالها" قبل الإصدار ، ولكن كيف يمكن إطلاق إصدارات LineageOS مع فتح هذه المشكلة؟

ليس من المنطقي التحدث عن هجوم حيث يتم استبدال التطبيق في صورة النظام. سيحتاج المهاجم بالفعل إلى الحصول على حق الوصول الكامل إلى الجذر لإعادة التحميل على أنه قابل للكتابة وتعديله. يمكنهم أيضًا تعديل القائمة البيضاء ...

وهذا أيضًا شيء قلته أيضًا عدة مرات.

لست متأكدًا من كيفية فهم هذه الفقرة بشكل مختلف:

على هذا النحو ، أرى أنه من الكافي "سد فجوة الأمان" من خلال تقديم إما إنشاءات "المستخدم" أو عن طريق التثبيت المسبق لحزمة تملأ المكان. نظرًا لأن أي شخص لا يزال بإمكانه استبدال WebView سيظل بحاجة إلى الوصول إلى الجذر ، فهو موجود بالفعل. لا ترى كيف تزداد الأمور سوءًا بالنسبة للضحية إذا تمكن المهاجم أيضًا من استبدال عرض الويب على رأس الوصول الكامل على الأقل إلى قسم النظام.

للعودة إلى الموضوع:

يتلخص في:
هل هناك جزء كبير من الأجهزة التي تشغل Bromite WebView حيث لا يوجد لدينا خيار لتجاوز القائمة البيضاء WebView؟

على حد علمي ، توجد ذاكرة قراءة فقط (ROM) حيث يمكن استبدال تطبيق webview apk المثبت مسبقًا في النظام وهو يعمل.
على حد علمي ، ليس لدينا طريقة معروفة وموثوقة لتغيير قائمة WebView البيضاء على ROM هذه لاستيعاب أي شيء بخلاف com.android.webview حالة عدم وجود دعم Runtime Resource Overlay.

إذا كنت مخطئًا في هذا الأمر ، إذا كان تصحيح framework-res.apk يعمل على الأقل عندما يعمل استبدال webview apk (نظرًا لأن النظام يمكنه أو يجب عليه التحقق من توقيع ملف apk هذا أيضًا أم لا؟) أو إذا وجدنا طريقة جديدة لتجاوز القائمة البيضاء ، فأنا لا أرى أي شيء أكثر من ذلك يمكن أن يقف ضد اسم حزمة فريد ، والذي ، مرة أخرى ، أعتقد أيضًا أنه الشيء الصحيح الذي يجب القيام به.

تحرير: مرة أخرى ، فإن إهمال أي إصدار android لا يمكن الاعتماد عليه في القائمة البيضاء (من وجهة نظر Bromiet WebViews) لا يزال خيارًا هنا أيضًا.

لا يغير اختراقه في إصدار حالي عن طريق التخلي عن توافق نظام التشغيل والتحديث الذي تم التحقق منه (إذا أجريت أي تغييرات ، لقد كسرت التحديثات المتزايدة) أي شيء حقًا.

thestinger مع Magisk يمكنك استبدال ملفات النظام دون كسر التحديثات الإضافية وربما حتى من دون كسر AVB (تماما) كذلك. ما زلت بحاجة إلى محمل إقلاع غير مؤمّن ، لكن أي أقسام أخرى باستثناء boot و userdata تظل دون أن يعبث بها.

جوهر AVB هو التحقق من vbmeta وما تشير إليه عبر التجزئة.

هناك الكثير من الفرضيات هنا. الأساس المنطقي الخاص بي هو أكثر أو أقل: إذا كان com.android.webview مفيدًا للمستخدمين غير الجذر لمثل هذه الأقراص المدمجة غير الآمنة ، فليس لدي اهتمام بدعمهم.

@ csagan5 أنت تشير إلى تضع في القائمة البيضاء com android.webview بدون تثبيت توقيع على الرغم من عدم التثبيت المسبق لأي حزمة com.android.webview ، مما يسمح بتثبيت أي موفر WebView com.android.webview كتطبيق مستخدم دون العبث النظام هل فهمت هذا صحيح؟

أعتقد أيضًا أن هذا سيناريو لا يحتاج إلى دعم ووصفه بأنه "غير آمن" و "بعيد الاحتمال للغاية" في مرحلة ما.

لست متأكدًا مما إذا كان يتيح لك فعل ذلك.

في نظام Android 7 والإصدارات الأحدث ، سيعمل هذا فقط على تصميمات userdebug ولكن هذا ممكن.

في نظام Android 6 والإصدارات الأقدم ، أعتقد أنه ممكن بشكل عام (عملت القائمة البيضاء WebView أيضًا بشكل مختلف في ذلك الوقت).

لدي بالفعل جهاز واحد يناسب هذا السيناريو:
واجه مخزون Lollipop ROM على OnePlus X هذه المشكلة الأمنية ، حيث لم يقموا بتجميع حزمة com.android.webview على الرغم من إدراجه في القائمة البيضاء ومن الممكن تثبيت bromite webview دون العبث بالنظام. لم أتحقق مما إذا كانوا قد أطلقوا هذا الأمر على أنه إصدار userdebug أيضًا ، لكنه جهاز حقيقي حقيقي يناسب السيناريو. لكن مرة أخرى ، غير محتمل للغاية.

إذا كنا نتحدث عن الأجهزة القديمة ، فقد يكون من الجدير بالذكر أيضًا أن التمهيد المحقق غير موجود على هذه الأجهزة.
تذكر أنه تم إصدار Bromite WebView أيضًا بـ minApiVersion من 19 .

جعلني هذا أدرك أنني أسأت فهم شيء ما في تعليق سابق ، فقمت بحذفه لأنه غير صالح وسأعيد صياغته الآن:

لذا ، أعتقد أن SebiderSushi يمكن تقسيم البحث إلى قسمين:

1. خيارات لتثبيت WebView بدون جذر ومحمل إقلاع غير مؤمن (على سبيل المثال ، عملية تمهيد غير مؤكدة)
2. خيارات لتثبيت WebView مع الجذر

لا أرى كيف يمكن أن يقف هذا التمييز ، لأن:

• عند التعامل مع عملية تمهيد تم التحقق منها ، فإن الطريقة الوحيدة هي تحميص دعم البروميت في ذاكرة القراءة فقط بواسطة المنشئ ، ولن يساعد الجذر.
• عند التعامل مع جهاز بدون دعم تمهيد تم التحقق منه أو محمل إقلاع غير مؤمن ، قد يتم العبث بصورة النظام بأي طريقة ضرورية للبدء بها.

لتلخيص:

• يجب إجراء / دعم تغيير القائمة البيضاء لعرض الويب من قبل أي شخص ينشئ صورة النظام أو ينتهك نموذج الأمان
• يتطلب تغيير القائمة البيضاء لعرض الويب تغيير محتويات قسم النظام ، على الأقل لأنها فعالة في وقت التشغيل
• كيف يحصل المستخدم على القدرة على تعديل نظامه هو خارج نطاق مسؤوليتنا. قد يستخدمون الوصول إلى الجذر في وقت التشغيل لوضع الملفات في قسم النظام الفعلي الخاص بهم ، وقد يقوموا بوميض نظام مصحح عبر fastboot ، أو استخدام استرداد مخصص للتلاعب بتخزينهم ، أو وسائل أخرى مثل magisk أو أي شيء حرفيًا ، ولكنه لا يحدث فرقًا بالنسبة لـ طريقة تجاوز القائمة البيضاء لعرض الويب على حد علمي

طالما أننا لا نخترق إطار العمل في وقت التشغيل للسماح بحزمة عرض ويب مخصصة كمزود للموقع.

حسنًا ، لقد استثمرت كثيرًا في هذا الآن ، حرفيًا كل ما أريد أن أقوله هو أنه ، على النحو الأمثل ، يجب علينا

• لديك طريقة لإدراج اسم حزمة مخصص في القائمة البيضاء على جميع أجهزة / إصدارات android مدعومة بواسطة bromite webview ، مهما كانت هذه الطريقة.

أو

• قم بإسقاط دعم البروميت علنًا (أعرف أن دعم هذا لم يكن رسميًا أبدًا) لجميع إصدارات / أجهزة android التي لا يكون ذلك ممكنًا فيها. هذا لا يعني بالضرورة تغيير minApiVersion نظرًا لأنه لا يزال بإمكان المستخدمين محاولة اكتشاف تجاوز القائمة البيضاء من تلقاء أنفسهم ، ولكن يجب الاعتراف بهذه النتيجة الحقيقية في حالة المضي قدمًا في استخدام اسم حزمة فريد.

أو

• استمر في نشر عرض الويب على الأقل باستخدام com.android.webview كاسم حزمة

يجب استخدام اسم حزمة فريد في أسرع وقت ممكن ، لكنني أعتقد أن هذه الجوانب يجب أن تمنع إهمال اسم الحزمة com.android.webview في إصدارات Bromite WebView.

بمجرد حل جوانب الحظر هذه ، لا أرى أي شيء آخر من شأنه أن يعيق إهمال اسم الحزمة com.android.webview .

في النهاية ، أرى مقايضة هنا.
كما هو الحال حاليًا ، لم أتمكن من تسجيل تراكب موارد وقت التشغيل على نظامي Android 7 و 8. إن تصحيح framework-res.apk شيء لم أجربه بعد ولكني أشك في أنه يعمل بشكل موثوق. على أقل تقدير ، لا يوجد حل عام لذلك ، سيكون من الضروري وجود مُثبِّت موثوق به قادر على القيام بذلك حيث لا يستطيع كل مستخدم القيام بذلك يدويًا.
من ناحية أخرى ، فإن استخدام اسم حزمة فريد سيوفر فقط ميزة حقيقية بمجرد أن تبدأ ROM أو البائعين في إدراج Bromite WebView في القائمة البيضاء بالطريقة الصحيحة ولا أتوقع أن يحدث هذا على نطاق مناسب.
هذا هو كل الأسباب التي تجعلني أعتقد أنه في الوقت الحالي سيكون حل وسط صالحًا للالتزام بـ com.android.webview والسماح بشكل فعال بتثبيت bromite webview دون الحاجة إلى تصحيح القائمة البيضاء على عدد من الأجهزة عن طريق استبدال عرض الويب apk في النظام مع apk بروميت. يمكن إجراء هذه العملية المعينة ببساطة باستخدام ملف apk stub لهذه الخطوة. إذا كان من الممكن التحكم في القائمة البيضاء لعرض الويب ، فلن تكون هناك حاجة إلى ملف apk stub.

يجب أن تكون كل خطوة واضحة أيضًا بشأن التداعيات الأمنية.

هذه هي الآثار الأمنية التي أراها أثناء تثبيت Bromite WebView:

• استخدام Bromite WebView
  -> يجب أن تثق في @ csagan5 نظرًا لأنه يتم تحميل أي عرض
• Bromite WebView باسم حزمة فريد مدعوم بشكل صحيح بواسطة ROM
  -> هل تثق في ROM الخاص بك؟
• تغيير القائمة البيضاء لموفر WebView
  -> قد تسمح القائمة البيضاء الجديدة لـ WebViews التي لا تثق بها أو تثبت أي عرض ويب بدون توقيع لم يتم تثبيته مسبقًا أثناء تشغيل AOSP userdebug .
• وضع الملفات في قسم النظام الخاص بك
  -> الآثار المعتادة لتلك التي نأمل أن يدركها أي شخص يفعل ذلك والتي لا تتحمل المنظمة البحرية الدولية مسؤولية دليل تثبيت عرض الويب لتغطيتها.
• فتح محمل الإقلاع الخاص بك
  -> انظر الشرح السابق
• استخدام برنامج تابع لجهة خارجية لتثبيت Bromite WebView في نظامك
  -> انظر الشرح السابق

للعودة إلى الموضوع:

يتلخص في:
هل هناك جزء كبير من الأجهزة التي تشغل Bromite WebView حيث لا يوجد لدينا خيار لتجاوز القائمة البيضاء WebView؟

على حد علمي ، توجد ذاكرة قراءة فقط (ROM) حيث يمكن استبدال تطبيق webview apk المثبت مسبقًا في النظام وهو يعمل.
على حد علمي ، ليس لدينا طريقة معروفة وموثوقة لتغيير قائمة WebView البيضاء على ROM هذه لاستيعاب أي شيء بخلاف com.android.webview حالة عدم وجود دعم Runtime Resource Overlay.

إذا كنت مخطئًا في هذا الأمر ، إذا كان تصحيح framework-res.apk يعمل على الأقل عندما يعمل استبدال webview apk (نظرًا لأن النظام يمكنه أو يجب عليه التحقق من توقيع ملف apk هذا أيضًا أم لا؟) أو إذا وجدنا طريقة جديدة لتجاوز القائمة البيضاء ، فأنا لا أرى أي شيء أكثر من ذلك يمكن أن يقف ضد اسم حزمة فريد ، والذي ، مرة أخرى ، أعتقد أيضًا أنه الشيء الصحيح الذي يجب القيام به.

تحرير: مرة أخرى ، فإن إهمال أي إصدار android لا يمكن الاعتماد عليه في القائمة البيضاء (من وجهة نظر Bromiet WebViews) لا يزال خيارًا هنا أيضًا.

أشياء زوجين

ما لم يتم توقيع rom الخاص بك باستخدام مفاتيح الاختبار ، لا يمكنك إعادة توقيع framework-res ، وإذا كان لا يزال يتعين عليك التوقيع عليه
يتحقق Android من دقة الإطار ومعظم الأجهزة bootloop إذا كان التوقيع خاطئًا

تحاول الوحدة النمطية الخاصة بي حاليًا فقط تمكين التراكب على وحدات التخزين المدمجة ، لكنني أجد في a10 بعض الجمارك أيضًا لا تحتوي على القائمة البيضاء اللازمة ، أو أن الدعائم التي أتحقق منها غير موجودة ، لذلك أخطط للانتقال لتضمينها دائمًا تراكب تجاوز القائمة البيضاء.

على أي حال ، يتطلب الأمر جذرًا أو محمل إقلاع غير مؤمّن في 99.9999999999999٪ من الحالات ، لذا سيكون من السهل تحديث طريقي لأي أسماء حزم. طرق التثبيت الأخرى ليست كثيرة بالرغم من أنها تميل إلى حدوث مشكلات على أي حال

إما أن تقوم بإدراج أحد التطبيقات المجمعة في نظام التشغيل دون تحديد دبوس مفتاح أو إدراج تطبيق غير مضمن في نظام التشغيل باستخدام دبوس مفتاح.

لا أستطيع التفكير في أي حالة يكون فيها استخدام com.android.webview مفيدًا. إذا كان هناك تطبيق مجمع بالفعل ، فلا يمكنك تثبيته.

السيناريو الوحيد غير الآمن هو عندما تكون هناك حزم مدرجة في القائمة البيضاء وتأتي ذاكرة القراءة فقط بدون تثبيت مثل هذه الحزم. المناقشات السابقة هنا حول هذه المسألة محيرة عندما لا يذكرون هذا الشرط صراحة.

هناك الكثير من الفرضيات هنا. الأساس المنطقي الخاص بي هو أكثر أو أقل: إذا كان com.android.webview مفيدًا للمستخدمين غير الجذر لمثل هذه الأقراص المدمجة غير الآمنة ، فليس لدي اهتمام بدعمهم.

لذا ، أعتقد أن SebiderSushi يمكن تقسيم البحث إلى قسمين:

1. خيارات لتثبيت WebView بدون جذر ومحمل إقلاع غير مؤمن (على سبيل المثال ، عملية تمهيد غير مؤكدة)
2. خيارات لتثبيت WebView مع الجذر

لقد قمت بالفعل بالكثير من التحقيقات ، ما قد يكون منطقيًا بالنسبة لي هو ترتيب هذا في نوع من دليل المستخدم / مخطط التدفق ؛ يجب أن تكون كل خطوة واضحة أيضًا بشأن التداعيات الأمنية.

لم ألتقي حتى الآن بمخزن مدمج يقوم بإدراج com.android.webview في القائمة البيضاء ناهيك عن عدم وجود توقيع مثبت (أعتقد أن إنشاء بكسل a10 سابقًا ولكن لم يعد بإمكاني التحقق منه) وستكون ذاكرة التخزين المؤقت هي إنشاءات المستخدم دون السماح بتشغيل webview كتطبيق مستخدم.
على الرغم من أن بعض OEM قد لا تقوم بفرض AVB بشكل كامل مما يسمح لنا بإجراء تعديلات ، إلا أنه يصبح من الصعب والأصعب تحميل قسم غير بيانات rw (انظر: EROFS ، ext4 ، الأقسام الديناميكية ، إلخ)

نتيجة لذلك ، لا أتحدث عن أي حالات استخدام تحافظ على AVB.

لست على دراية بأي ذاكرة ROM من شأنها أن تجمع دعم Bromite. هذا ما قصدته عندما كنت أقول

بالطبع يمكن إعادة النظر في هذه النقطة إذا كان الفريق الذي يقف وراء ذاكرة القراءة فقط المخصصة الموزعة على نطاق واسع (مثل LineageOS) سيكون على استعداد لإدراج اسم حزمة فريد من نوعه لبرنامج Bromite WebView في القائمة البيضاء.

لم أرغب في أي وقت في الإشارة إلى أي انتماء ولكن بدون حدوث مثل هذا الشيء ، فإن حالة الاستخدام الوحيدة المتبقية هي أن المستخدمين الذين لديهم محمل إقلاع غير مؤمن يقومون بتصحيح أقسام نظامهم أو تثبيت وحدات Magisk أو أيًا كان ما تقوم به المهمة.

تدعم بعض وحدات التخزين المخصصة AVB تمامًا ، ومن الناحية النظرية ، إذا كنت قد بنيت بنفسك ، فيمكنك التوقيع على تمهيد magisk المصحح بمفاتيحك ولديك جذر ولكن محمل إقلاع مغلق

لا أستطيع التفكير في أي حالة يكون فيها استخدام com.android.webview مفيدًا. [...] يمكنك تحويل الموارد إلى xml من ثنائي xml وتعديلها وتحويلها مرة أخرى. في كلتا الحالتين تقوم ببنائه في نظام التشغيل.

مكافحة المثال:

• محمل الإقلاع
• بناء المستخدم الذي يقوم بإدراج com.android.webview القائمة البيضاء بدون تثبيت توقيع
• عرض الويب المثبت مسبقًا مثبت كـ /system/app/webview/webview.apk
• لا يوجد دعم RRO (android 6 أو شيء ما)

يمكنني تثبيت Bromite WebView عن طريق التشغيل
على سبيل المثال ، cat bromitewebview.apk > /system/app/webview/webview.apk في TWRP.
ويمكنني تشغيل هذا واستخدام Bromite WebView.
فقط لأن Bromite WebView يستخدم حاليًا com.android.webview

كيف يمكنني استبدال القائمة البيضاء لعرض الويب في هذا السيناريو لدعم اسم حزمة فريد إذا لم يعمل الترقيع framework-res.apk لأنني لا أستطيع إعادة تسجيله باستخدام مفتاح النظام الأساسي؟

يختلف Webview أدناه 7 اختلافًا كبيرًا في كيفية عمله وأنا لا أقدم دعمًا رسميًا لشخص واحد ، على الرغم من أن لدي تقارير أنه يعمل على حوالي 6.0 روم

جعلني هذا أدرك أنني أسأت فهم شيء ما في تعليق سابق ، فقمت بحذفه لأنه غير صالح وسأعيد صياغته الآن:

لذا ، أعتقد أن SebiderSushi يمكن تقسيم البحث إلى قسمين:

1. خيارات لتثبيت WebView بدون جذر ومحمل إقلاع غير مؤمن (على سبيل المثال ، عملية تمهيد غير مؤكدة)
2. خيارات لتثبيت WebView مع الجذر

لا أرى كيف يمكن أن يقف هذا التمييز ، لأن:

• عند التعامل مع عملية تمهيد تم التحقق منها ، فإن الطريقة الوحيدة هي تحميص دعم البروميت في ذاكرة القراءة فقط بواسطة المنشئ ، ولن يساعد الجذر.
• عند التعامل مع جهاز بدون دعم تمهيد تم التحقق منه أو محمل إقلاع غير مؤمن ، قد يتم العبث بصورة النظام بأي طريقة ضرورية للبدء بها.

لتلخيص:

• يجب إجراء / دعم تغيير القائمة البيضاء لعرض الويب من قبل أي شخص ينشئ صورة النظام أو ينتهك نموذج الأمان
• يتطلب تغيير القائمة البيضاء لعرض الويب تغيير محتويات قسم النظام ، على الأقل لأنها فعالة في وقت التشغيل
• كيف يحصل المستخدم على القدرة على تعديل نظامه هو خارج نطاق مسؤوليتنا. قد يستخدمون الوصول إلى الجذر في وقت التشغيل لوضع الملفات في قسم النظام الفعلي الخاص بهم ، وقد يقوموا بوميض نظام مصحح عبر fastboot ، أو استخدام استرداد مخصص للتلاعب بتخزينهم ، أو وسائل أخرى مثل magisk أو أي شيء حرفيًا ، ولكنه لا يحدث فرقًا بالنسبة لـ طريقة تجاوز القائمة البيضاء لعرض الويب على حد علمي

نحن نفترض وجود قسم نظام لم يتم العبث به ، وبما أن magisk لا يعبث بالنظام ، يمكننا أيضًا افتراض أن حفنة من المستخدمين قد قاموا بفرض AVB إذا تم اتخاذ الخطوات المناسبة

اعتبارًا من الإصدار 5.0.1 ، أوقفت دعم non-magisk وإن كان إذا احتاجه عدد كافٍ من الأشخاص ، فسأقوم بتقييم إعادته

على أي حال ، يتطلب الأمر جذرًا أو محمل إقلاع غير مؤمّن في 99.9999999999999٪ من الحالات ، لذا سيكون من السهل تحديث طريقي لأي أسماء حزم. طرق التثبيت الأخرى ليست كثيرة بالرغم من أنها تميل إلى حدوث مشكلات على أي حال

أنا مهتم بطرق التثبيت الأخرى.

على أي حال ، يتطلب الأمر جذرًا أو محمل إقلاع غير مؤمّن في 99.9999999999999٪ من الحالات ، لذا سيكون من السهل تحديث طريقي لأي أسماء حزم. طرق التثبيت الأخرى ليست كثيرة بالرغم من أنها تميل إلى حدوث مشكلات على أي حال

أنا مهتم بطرق التثبيت الأخرى.

أعتقد أن nanodroid لديه مُثبِّت ولكنه يدفع ملف APK في مكانه في / النظام.

وبالطبع هناك طريقة القص واللصق اليدوية ولكن مع صور نظام RO التي أصبحت هي القاعدة ، ومن أجل عدم تعثر AVB / dm-verity ما لم يكن ذلك ضروريًا ، فإنني أنصح بعدم استخدام هذه الطريقة: P

اكتشفت اليوم أن إحدى الطرق للحصول على سلسلة signature التي يجب وضعها في القائمة البيضاء لعرض الويب هي كما يلي:
keytool -printcert -rfc -jarfile arm_SystemWebView.apk

(لقد قمت بتحديث صفحة الويكي الخاصة بي لتضمين هذه المعلومات)

في ملاحظة أخرى: لقد استخدمت للتو apktool لتغيير اسم الحزمة لعرض الويب بروميت. تبين أن مجرد تغيير package & أسماء الموفرين في البيان ثم إعادة التجميع يعمل بالفعل ويمكنني عرض مواقع الويب من خلال الحزمة التي قمت بالتلاعب بها وتثبيتها بهذه الطريقة.

إذا لم تكن هناك أية مشكلات عميقة ، فيمكن تحقيق البناء باستخدام اسمين للحزم من خلال تشغيل بعض أوامر shell قبل الإنشاء - وستقتصر الجهود المتزايدة على توفير الوقت ونشر الخدمات اللوجستية فقط.

ما رأيك @ csagan5 ؟ هل ستبدأ في الإفراج عن اثنين من أسماء الحزم إذا صمدت هذه النظرية؟
أو ربما يكفي فقط تركيب البروميت بالتوازي على أجهزة التطوير المحلية ...

تغيير package & أسماء الموفرين في البيان ثم إعادة تجميع الأعمال بالفعل

إعادة تجميع ماذا؟ يعمل مع أي نوع من framework-res.apk؟

هل ستبدأ في الإفراج عن اثنين من أسماء الحزم إذا صمدت هذه النظرية؟

لا بد لي من التبديل إلى اسم الحزمة الجديد على أي حال ، الجزء الوحيد غير الواضح هو كيفية توفير تعليمات الترحيل لجميع التركيبات الممكنة المختلفة. يمكنني البدء في إصدار كليهما لفترة من الوقت ولكني بحاجة إلى الحصول على تعليمات جاهزة قبل ذلك.

تغيير package & أسماء الموفرين في البيان ثم إعادة تجميع الأعمال بالفعل

إعادة تجميع ماذا؟ يعمل مع أي نوع من framework-res.apk؟

لقد اعتبرتها تعني عرض الويب ، حيث إن تعديل Framework-res يؤدي عمومًا إلى توقف الجهاز عن التشغيل

تغيير package & أسماء الموفرين في البيان ثم إعادة تجميع الأعمال بالفعل

إعادة تجميع ماذا؟ يعمل مع أي نوع من framework-res.apk؟

إعادة تجميع بروميت WebView. كنت أشير فقط إلى إمكانية تغيير اسم حزمة Bromite WebView دون أي تغييرات مزعجة للحفاظ على العمق لأي شيء آخر غير البيان ، وبالتالي تقليل جهد الإفراج عن اسمي حزم في وقت واحد. آسف إذا لم تكن هذه معلومات جديدة لك.

هل ستبدأ في الإفراج عن اثنين من أسماء الحزم إذا صمدت هذه النظرية؟

لا بد لي من التبديل إلى اسم الحزمة الجديد على أي حال ، الجزء الوحيد غير الواضح هو كيفية توفير تعليمات الترحيل لجميع التركيبات الممكنة المختلفة. يمكنني البدء في إصدار كليهما لفترة من الوقت ولكني بحاجة إلى الحصول على تعليمات جاهزة قبل ذلك.

ولكن نظرًا لعدم وجود بيانات مستخدم متضمنة ، فإن الأمر يتعلق بتثبيت الحزمة الجديدة واختيارها كمزود عرض الويب ، لذلك يتعلق الأمر في الغالب بكيفية إيصال الأخبار إلى كل مستخدم ، أليس كذلك؟

ما مقدار الجهد المبذول لتجميع متصفح Bromite مع دعم لكونك مزودًا لعرض الويب أيضًا؟

ما مقدار الجهد المبذول لتجميع متصفح Bromite مع دعم لكونك مزودًا لعرض الويب أيضًا؟

Kinda عديم الجدوى كما هو الحال في متصفح 10+ وعرض الويب منفصلان في الكروم المنبع

إنها ليست منفصلة حقًا ولكنها مقسمة إلى 3 تطبيقات: المتصفح و WebView ومكتبة apk التي توفر معظم الكود المشترك بينها.

هدف WebView المستقل حديث تمامًا ولا يزال مدعومًا بالكامل. أهداف apk للمتصفح المستقل غير مخصصة للاستخدام على الأجهزة الحديثة. إذا كنت ترغب في تجنب تقسيم المكتبة بينما لا تزال مبنى حديثًا ، فستحتاج إلى تحديد هدف جديد.

إنها ليست منفصلة حقًا ولكنها مقسمة إلى 3 تطبيقات: المتصفح و WebView ومكتبة apk التي توفر معظم الكود المشترك بينها.

بالنسبة إلى نوايانا ، فإن الحزم المنفصلة للتطبيقات ، على الرغم من أنني على دراية بـ trichrome vs monochrome

سنفترض أن مكتبة trichrome متاحة على الأجهزة التي تحتاجها ، ونحن قلقون فقط بشأن عرض الويب وإلى حد ما المتصفح

يتم استخدام المكتبة بواسطة المتصفح و WebView apks - لا شيء آخر. يوفر الجزء الأكبر من التعليمات البرمجية.

يتم استخدام المكتبة بواسطة المتصفح و WebView apks - لا شيء آخر. يوفر الجزء الأكبر من التعليمات البرمجية.

حسنًا ، نعم ما أقوله :)

ما مقدار الجهد المبذول لتجميع متصفح Bromite مع دعم لكونك مزودًا لعرض الويب أيضًا؟

كان الدافع وراء هذا السؤال هو الفكرة التالية:
متصفح Bromite له اسم الحزمة الخاص به ، لذلك يمكن بالفعل إدراجه في القائمة البيضاء بشكل صحيح. إذا كان قادرًا على توفير إمكانات عرض الويب ، فيجب أن يكون معظم المستخدمين على ما يرام بعد تثبيته.
أيضًا ، بالنسبة لمستخدمي كل من عرض الويب بروميت ومتصفح بروميت ، سيؤدي ذلك إلى تقليل استخدام التخزين والنطاق الترددي.

من المؤكد أن تصحيح أخطاء عرض الويب المستقل بالتوازي مع تثبيت حزمة عرض ويب من الكروم المنبع سيظل مستحيلاً.

أما بالنسبة إلى Trichrome مقابل Monochrome: فهما مجرد طريقتين لإزالة تكرار الكود ، أليس كذلك؟ وكلاهما صالح ويعمل ، حتى على نظام Android 10+؟
على الأقل هذه هي الطريقة التي قرأت بها منشور XDA هذا ، مع الفوائد على Monochrome التي تتمثل في أن Trichrome لديه "عدد أقل من الحالات والأخطاء الخاصة الغريبة."

لا ، إنه ليس مجرد اختيار بين طرق مختلفة لمشاركة التعليمات البرمجية.

ما مقدار الجهد المبذول لتجميع متصفح Bromite مع دعم لكونك مزودًا لعرض الويب أيضًا؟

كان الدافع وراء هذا السؤال هو الفكرة التالية:
متصفح Bromite له اسم الحزمة الخاص به ، لذلك يمكن بالفعل إدراجه في القائمة البيضاء بشكل صحيح. إذا كان قادرًا على توفير إمكانات عرض الويب ، فيجب أن يكون معظم المستخدمين على ما يرام بعد تثبيته.
أيضًا ، بالنسبة لمستخدمي كل من عرض الويب بروميت ومتصفح بروميت ، سيؤدي ذلك إلى تقليل استخدام التخزين والنطاق الترددي.

من المؤكد أن تصحيح أخطاء عرض الويب المستقل بالتوازي مع تثبيت حزمة عرض ويب من الكروم المنبع سيظل مستحيلاً.

أما بالنسبة إلى Trichrome مقابل Monochrome: فهما مجرد طريقتين لإزالة تكرار الكود ، أليس كذلك؟ وكلاهما صالح ويعمل ، حتى على نظام Android 10+؟
على الأقل هذه هي الطريقة التي قرأت بها منشور XDA هذا ، مع الفوائد على Monochrome التي تتمثل في أن Trichrome لديه "عدد أقل من الحالات والأخطاء الخاصة الغريبة."

Trichrome هو Android 10+ ، أحادي اللون = <9

لا يحدد نظام الإنشاء المنبع أيضًا أهداف المستعرض المستقل لنظام Android الحديث. إذا كنت ترغب في ذلك ، فأنت بحاجة إلى تحديدها بنفسك ، وإلا فإنك ستنشر تصميمات لا تدعم النظام الأساسي الحديث بشكل كامل.

بالنسبة إلى WebView ، يتم دعم هدف WebView المستقل بشكل كامل عبر جميع الإصدارات المدعومة. إذا كنت ترغب في مشاركة الكود مع المتصفح ، يتم استخدام Trichrome على Android 10+ و Monochrome للإصدارات السابقة (منذ أن أصبح مدعومًا). اللون الأحادي غير مدعوم على Android 10+ ولا يدعم Trichrome قبل Android 10.

من الخطأ استخدام ChromeModernPublic على نظام Android 7+. تحتاج إلى تحديد الهدف الخاص بك لمتصفح مستقل. ستعمل ، لكنها لن تدعم ميزات النظام الأساسي الحديثة بما في ذلك تحسينات الأمان المرتبطة بمستوى واجهة برمجة التطبيقات.

من الخطأ أيضًا استخدام Monochrome على Android 10+ ، ولن يعمل كمزود WebView على الإطلاق. سيوفر فقط متصفحًا يعمل بنفس المشكلة مثل ChromeModernPublic ، بمستوى واجهة برمجة تطبيقات مستهدف أقل تقدمًا.

يتم استخدام المكتبة بواسطة المتصفح و WebView apks - لا شيء آخر. يوفر الجزء الأكبر من التعليمات البرمجية.

يمكن لملفات APK تجميع مكتبات .so وإذا كانت متطابقة تمامًا ، فستتم مشاركتها في الذاكرة (كما يفعل أي نظام Linux) مما يقلل من مساحة الذاكرة لكلا التطبيقين.

من الخطأ استخدام ChromeModernPublic على Android 6+. تحتاج إلى تحديد الهدف الخاص بك لمتصفح مستقل. ستعمل ، لكنها لن تدعم ميزات النظام الأساسي الحديثة بما في ذلك تحسينات الخصوصية / الأمان المرتبطة بمستوى واجهة برمجة التطبيقات المستهدفة.

thestinger ChromeModernPublic ليس الهدف الصحيح لمتصفح مستقل؟ ماذا تستخدم للفاناديوم؟ لطالما كنت أشير إلى https://chromium.googlesource.com/chromium/src/+/master/docs/android_build_instructions.md#Multiple -Chrome-Targets وهو نادر بعض الشيء في حالات الاستخدام.

يمكن لملفات APK تجميع مكتبات. أيضًا ، وإذا كانت متطابقة تمامًا ، فستتم مشاركتها في الذاكرة (كما يفعل أي نظام Linux) مما يقلل من مساحة الذاكرة لكلا التطبيقين

تقوم TrichromeLibrary بذلك مع كل من المكتبة الأصلية والموارد الأخرى. يستخدم البنية الأساسية القياسية لاستخدام apk كمكتبة (والتي تتجاوز مجرد مكتبة أصلية) بطريقة تمت مصادقتها بشكل صحيح.

thestinger ChromeModernPublic ليس الهدف الصحيح لمتصفح مستقل؟ ماذا تستخدم للفاناديوم؟ لطالما كنت أشير إلى https://chromium.googlesource.com/chromium/src/+/master/docs/android_build_instructions.md#Multiple -Chrome-Targets وهو نادر بعض الشيء في حالات الاستخدام.

@ csagan5 لا يوجد هدف مستعرض مستقل حديث لأن Chrome لا يستخدمه لذلك لم يحدده. يستخدم الفاناديوم أهداف Trichrome. TrichromeChrome + TrichromeLibrary بدون شحن TrichromeWebView هي الطريقة الوحيدة للحصول على متصفح حديث باستخدام أهداف المنبع فقط. نحن نستخدم الإصدار 64_32 من الأهداف بحيث لا يتم دعم 64 بت فقط ولكن يفضل أيضًا على 32 بت بحيث تعمل جميع عمليات المتصفح على أنها 64 بت وتعمل عارضات WebView على أنها 64 بت.

ستحتاج إلى إنشاء مستعرض حديث قائم بذاته يستهدف نفسك للحصول عليه بدون تقسيم TrichromeLibrary. لست متأكدًا من عدد التغييرات التي تتجاوز targetSdkVersion. يعد استخدام أهداف 64_32 أيضًا الطريقة الصحيحة لتفضيل عمليات 64 بت وهذا جزء من البنية الأساسية لبناء Trichrome. يمكنك استخدام Trichrome بدون WebView (فقط باستخدام المتصفح والمكتبة apk) ولكن لم يتم إعداده لإنشاء متصفح apk واحد بدون المكتبة.

الحديث لا يعني في الواقع الحديث - بل كان يعني الحديث في وقت وجوده ، مقارنةً بالأقدم. تم استبداله بـ Monochrome ثم Trichrome. لا يتم شحن Chrome أبدًا كمتصفح مستقل بدون WebView لذلك لا يوجد هدف رئيسي لشيء لا يستخدمونه مطلقًا. من الممكن جدًا القيام بذلك ولكنهم لا يفعلون ذلك لأنهم لا يستخدمون ذلك.

نحن نستخدم الإصدار 64_32 من الأهداف بحيث لا يتم دعم 64 بت فقط ولكن يفضل أيضًا على 32 بت بحيث تعمل جميع عمليات المتصفح على أنها 64 بت وتعمل عارضات WebView على أنها 64 بت.

يقوم Bromite ببناء الإصدار 64 بت فقط من ملفات APK ، لذا أعتقد على الأقل في هذا الجانب أن العمليات لا يمكن أن تعمل بأكثر من 32 بت.

ستحتاج إلى إنشاء مستعرض حديث قائم بذاته يستهدف نفسك للحصول عليه بدون تقسيم TrichromeLibrary. لست متأكدًا من عدد التغييرات التي تتجاوز targetSdkVersion.

يمكن أن يكون حمام دم ، لكنني مضطر للمحاولة الآن.

يعد استخدام أهداف 64_32 أيضًا الطريقة الصحيحة لتفضيل عمليات 64 بت وهذا جزء من البنية الأساسية لبناء Trichrome.

بالتأكيد ، سيكون من المفيد أن يكون متوافقًا مع معماريات 32 بت و 64 بت.

الحديث لا يعني في الواقع الحديث - بل كان يعني الحديث في وقت وجوده ، مقارنةً بالأقدم. تم استبداله بـ Monochrome ثم Trichrome.

نعم ، كنت على دراية بنسبية "الحديث" - ولكن ما فاجأني من مشاركاتك هو أن هناك بالفعل اختلافًا جوهريًا في ميزات الأمان (وربما لا يتعلق بالأمان وحده؟) عند استخدام MonoChrome <Android10 و TriChrome> = Android10. لطالما كان لدي انطباع بأن الميزة الوحيدة هي توفير المكتبات / الذاكرة المشتركة جنبًا إلى جنب مع SystemWebView ، ولا شيء آخر.

هل تهتم بشرح هذه الاختلافات ، أو توجهني بطريقة أخرى إلى بعض الوثائق الرسمية لكي أتعرف عليها؟ أريد بالتأكيد معالجة هذه المشكلة بمجرد أن أفهم كيانها.

نحن نستخدم الإصدار 64_32 من الأهداف بحيث لا يتم دعم 64 بت فقط ولكن يفضل أيضًا على 32 بت بحيث تعمل جميع عمليات المتصفح على أنها 64 بت وتعمل عارضات WebView على أنها 64 بت.

يقوم Bromite ببناء الإصدار 64 بت فقط من ملفات APK ، لذا أعتقد على الأقل في هذا الجانب أن العمليات لا يمكن أن تعمل بأكثر من 32 بت.

ستحتاج إلى إنشاء مستعرض حديث قائم بذاته يستهدف نفسك للحصول عليه بدون تقسيم TrichromeLibrary. لست متأكدًا من عدد التغييرات التي تتجاوز targetSdkVersion.

يمكن أن يكون حمام دم ، لكنني مضطر للمحاولة الآن.

أتذكر مناقشة مجموعات Google حول ثلاثي الألوان مقابل أحادي اللون ولكن لا يمكنني العثور عليها الآن

@ csagan5 طالما تم تعيين targetSdkVersion على القيمة المناسبة (29 لنظام Android 10) ، فإنها ليست مشكلة كبيرة كما كانت من قبل ، وأعتقد أنهم ربما قاموا بتغيير هذا الجزء لجميع الأهداف الآن بسبب متطلبات متجر Play.

طالما تم تعيين targetSdkVersion على القيمة المناسبة (29 لنظام Android 10) ، فإنها ليست مشكلة كبيرة كما كانت من قبل ، وأعتقد أنهم ربما قاموا بتغيير هذا الجزء لجميع الأهداف الآن بسبب متجر Play المتطلبات.

حسنا، شكرا لردك. لذلك يمكنني تجنب استخدام TriChrome بمجرد إعادة إنشاء ChromeModernPublic باستخدام targetSdkVersion ؟ من المنطقي أن عدم تضمين الروابط القديمة يقلل من التعرض لواجهات برمجة التطبيقات الأقل أمانًا.

يجب أن يكون targetSdkVersion دائمًا 29 بغض النظر عن minSdkVersion. يحتوي Trichrome على minSdkVersion أعلى بكثير ويتجنب تضمين الأشياء القديمة واستخدام الأساليب القديمة مثل الرابط المجنون. لست متأكدًا تمامًا من كيفية إعداد هدف متصفح مستقل وحديث حقًا في الوقت الحالي. هناك بعض الأشياء التي تحتاج إلى تعديل.

thestinger لدي سؤال حول Trichrome. تشير الإرشادات هنا إلى أن Trichrome سينتج ملفين ، TrichromeChrome.aab و TrichromeLibrary.apk . من وجهة نظري ، TrichromeLibrary.apk هو فقط الملفات المكتوبة التي لا تحتوي على التشغيل الرئيسي ، و TrichromeChrome.aab هو ملف حزمة لا يمكن تثبيته مباشرة على هاتف مثل .apk . إذن ، كيف تقوم بالفعل بتثبيت المتصفح بالكامل ، دون القيام بشيء خيالي مثل استخراج apk من aab؟

يمكنك إنشاء ملف apk عالمي من الحزمة ، أو يمكنك إنشاء ملف apk مخصص للجهاز الذي تقوم بتثبيته وهو ما يفعله متجر Play للمطورين الذين يقدمون مفاتيح التوقيع الخاصة بهم إلى Google. أداة إنشاء تطبيقات (عالمية أو أكثر تخصصًا للأجهزة) مفتوحة المصدر (bundletool). أوصي بالنظر إلى generate_release.sh في مستودع الفاناديوم.

@ csagan5
تضمين التغريدة

لدي هاتف Motorola One Power ،
NOROOT-Locked Bootloader.
لا كروم مثبت.
تم تثبيت com.google.android.webview مسبقًا فقط والذي قمت بإلغاء تثبيته باستخدام
adb shell pm uninstall --user 0 com.google.android.webview

النجاح

المشكلة - تم تثبيت البروميت ولكن لم يظهر في إعدادات التطوير

framework-res.apk res / xml / config_webview_packages.xml

يعطي هذا الناتج أي عرض ويب واحد فقط تم تعريفه بدون توقيع

E: webviewproviders (السطر = 17)
E: webviewprovider (السطر = 19)
ج: availableByDefault = (النوع 0x12) 0xffffffff
ج: الوصف = "Android WebView" (Raw: "Android WebView")
ج: اسم الحزمة = "com.android.webview" (الخام: "com.android.webview")

adb shell dumpsys webviewupdate
يعطي هذا الإخراج

حالة خدمة تحديث WebView الحالية
تم تمكين المنطق الاحتياطي: خطأ
تم تمكين العمليات المتعددة: صحيح
حزمة WebView الحالية (الاسم ، الإصدار): (com.google.android.webview، 77.0.3865.92)
الحد الأدنى للإصدار الهدف SDk: 29
الحد الأدنى لرمز إصدار WebView: 386509238
عدد عمليات إعادة التشغيل التي بدأت: 2
عدد ريلروس المنتهية: 2
حزمة WebView قذرة: خطأ
أي حزمة WebView مثبتة: صحيح
حزمة WebView المفضلة (الاسم ، الإصدار): (com.google.android.webview، 77.0.3865.92)
حزم WebView:
تم تثبيت / تمكين الحزمة الصالحة com.google.android.webview (اسم الإصدار: 77.0.3865.92 ، رمز الإصدار: 386509238 ، targetSdkVersion: 29) لجميع المستخدمين
لم يتم تثبيت com.google.android.webview.beta.
لم يتم تثبيت com.google.android.webview.dev.
لم يتم تثبيت com.google.android.webview.canary.
لم يتم تثبيت com.google.android.webview.debug.
حزمة غير صالحة com.android.webview (اسم الإصدار: 83.0.4103.119 ، رمز الإصدار: 1592784620 ، targetSdkVersion: 29) ، السبب: توقيع غير صحيح

إنه يعرض توقيعًا غير صحيح لبروميت وليس لعرض ويب آخر مثل com.google.android.webview على الرغم من أنه لم يتم تعريفه في framework-res.apk

@ csagan5
تضمين التغريدة
توقيع غير صحيح

إنه يعرض توقيعًا غير صحيح لبروميت وليس لعرض ويب آخر مثل com.google.android.webview على الرغم من أنه لم يتم تعريفه في framework-res.apk

في الواقع ، لدي نفس المشكلة مع Android 10 الخاص بي على Huawei p smart 2019.