كشفت Google عن تحديث النظام الديناميكي، وهي طريقة جديدة لتثبيت GSI في Android Q والتي لا تتطلب إلغاء قفل أداة تحميل التشغيل.
بالتزامن مع إصدار Android 8.0 Oreo، كشفت Google النقاب عن مشروع التريبل: إعادة تصميم رئيسية في الطريقة التي يتواصل بها إطار عمل نظام التشغيل Android مع HALs للموردين و Linux kernel. Treble هي مبادرة رئيسية مصممة لتقليل إصدار نظام Android الأساسي و تجزئة التصحيح الأمني، وجميع الأجهزة التي تحمل علامة Android والتي يتم تشغيلها باستخدام Android Pie مطلوبة لدعم Project Treble. يختبر مصنعو المعدات الأصلية والبائعين توافق Treble عن طريق تشغيل صورة النظام العامة (GSI) — وهي نسخة خالصة من نظام Android من AOSP — وتمرير مجموعة اختبار البائع (VTS) واختبار التوافق مع صورة النظام العامة (CTS-on-GSI). لقد أثبت GSI فائدته ليس فقط في السماح لمهندسي البرمجيات العاملين لدى مصنعي المعدات الأصلية باختبار التوافق الثلاثي، ولكنه فتح أيضًا الباب أمام مجتمع ROM مخصص كبير على XDA. بالنسبة لإصدار Android Q، تريد Google أن تجعل GSIs مفيدة لمجموعة أخرى: مطوري التطبيقات.
منذ أول إصدار مستقر وإسقاط التعليمات البرمجية المصدر لأي إصدار معين من نظام Android الأساسي، عادةً ما يأتي ذلك
في أغسطس، يحتاج المطورون الذين يرغبون في اختبار إصدار Android التالي على جهاز حقيقي عادةً إلى الوصول إلى هاتف Google الذكي إذا كانوا لا يريدون انتظار وصول التحديث إلى أجهزتهم الخاصة. ومع ذلك، عملت Google مع مصنعي المعدات الأصلية لجلب أندرويد بي بيتا للعديد من الأجهزة في العام الماضي، وقد تابعوا ذلك هذا العام من خلال أندرويد كيو بيتا. إلى جانب الإصدار التجريبي الرسمي من Android Q، أصدرت Google هذا العام أيضًا إصدارًا تجريبيًا Q بيتا GSI الرسمية لذلك يمكن لأي مطور لديه جهاز متوافق مع Project Treble تثبيت أحدث إصدار من Q دون الحاجة إلى الانتظار شهورًا حتى يصل الإصدار إلى أجهزتهم. تمنح هذه الطريقة الجديدة لاختبار إصدار Android التالي للمطورين المزيد من الفرص، وبالتالي مزيدًا من الوقت، لاختبار تطبيقاتهم في مقابلها تغييرات كبيرة في أندرويد.للأسف الطريقة الحالية تركيب جي اس اي يمكن أن يكون صعبا. ويتطلب الأمر إلغاء قفل أداة تحميل التشغيل - مما يعني مسح جميع بيانات المستخدم و/أو إلغاء الضمان - ووميض صورة عبر بروتوكول التشغيل السريع. إنها ليست عملية سريعة وبسيطة يجب على مطور التطبيقات القيام بها، إذا كان على أجهزته حتى أنه يسمح بفتح أداة تحميل التشغيل. لهذا السبب، بالنسبة ل الأشهر القليلة الماضية، عملت Google على طريقة جديدة لتشغيل GSIs. أدخل ميزة جديدة تسمى Dynamic System Update أو DSU.
(تم تطوير هذه الميزة مسبقًا تحت أسماء "Live Image" و"Dynamic Android" و"Android on Tap"، لذا لا تتفاجأ إذا أطلقت عليها Google اسمًا آخر في غضون أسابيع أو أشهر قليلة.)
تحديثات النظام الديناميكية في Android Q
الهدف من ميزة DSU هو السماح للمطور بالتمهيد إلى GSI دون التدخل في التثبيت الحالي. وهذا يعني أن أداة تحميل التشغيل لا تحتاج إلى إلغاء القفل ولا يلزم مسح بيانات المستخدم. تم أيضًا تبسيط عملية التثبيت إلى حد كبير حيث قدمت Google واجهة سطر أوامر عبر ADB وتطبيقًا يمكن التحكم فيه عبر المقاصد. إليك ما يبدو عليه تشغيل GSI باستخدام DSU:
في هذا الفيديو*، تتم إعادة تشغيل هاتف Google Pixel 3 XL الذي يعمل بنظام التشغيل Android Q beta 3 في GSI. في هذه البيئة، يمكن لمطور التطبيق تثبيت تطبيقه واختباره من أجل توافق Q API. وعندما ينتهوا من الاختبار، يمكنهم ببساطة إعادة التشغيل مرة أخرى إلى برنامج Q beta 3 العادي الموجود على الجهاز. أنت في الأساس تقوم بتشغيل GSI بشكل مزدوج حتى تتمكن من اختبار تطبيقك بأمان!
*لقد سجلنا هذا الفيديو في Google I/O 2019 عندما لم تكن DSU متاحة للعامة بعد، لذلك تم تعديل الإصدار التجريبي Q beta 3 المبني على Pixel 3 XL الذي تم تصويره قليلاً بواسطة Google ليشمل دعم DSU. الأجهزة التي تعمل بنظام Q beta 4 والإصدارات الأحدث مؤهلة لدعم DSU إذا كانت تستوفي المتطلبات أدناه.
متطلبات تحديثات النظام الديناميكية
لم يكن الحصول على ما هو في الأساس تشغيل مزدوج وتشغيله مهمة سهلة بالنسبة إلى Google. كان لا بد من إجراء تغييرات كبيرة على طريقة إدارة الأقسام على Pixel 3، وهو اختبار Google لـ DSU. وبالتالي، فإن الشرط الرئيسي الأول لدعم DSU هو أن الجهاز يدعم الأقسام الديناميكية. تتضمن الأقسام الديناميكية قسمًا حقيقيًا للتخزين مقسمًا إلى أقسام منطقية يمكن تغيير حجمها مثل النظام، والمورد، وODM، وOEM، والمنتج، وما إلى ذلك. أثناء تثبيت GSI، يتم حجز المساحة لأقسام النظام وبيانات المستخدم الجديدة عن طريق أخذ الكتل غير المستخدمة من قسم بيانات المستخدم الحالي. وبما أن هذه الأقسام الجديدة يمكن أن يصل حجمها إلى عدة غيغابايت، فإن دعم DSU منطقي فقط مع المنطق الأقسام وإلا فسيحتاج الجهاز إلى حجز عدة غيغابايت من مساحة التخزين بشكل دائم لـ GSI المنشآت.
تتضمن المتطلبات الأخرى قرص ذاكرة الوصول العشوائي، الذي يقرر ما إذا كان سيتم التمهيد للاسترداد أو النظام أو القسم المنطقي، وقسم البيانات التعريفية لتخزين البيانات التعريفية الخاصة بـ GSI. بشكل عام، العناصر الأساسية لدعم DSU هي متطلبات إطلاق Android Q، وفقًا لقائد مشروع Treble إليان مالشيف. نحن لسنا متأكدين إذا كل شئ ما هو مطلوب لدعم DSU هو أحد متطلبات إطلاق Android Q، ولكن يمكننا أن نفترض أن معظم الأجهزة، إن لم يكن جميعها، التي يتم تشغيلها باستخدام Android Q يستطيع دعم DSU حتى لو لم تطلب Google منهم ذلك حاليًا. حتى الآن، تحتوي هواتف Pixel 3 وPixel 3 XL وPixel 3a وPixel 3a XL فقط على أقسام ديناميكية، ومن بين هذه الأجهزة، يدعم Pixel 3 وPixel 3 XL فقط DSU في الإصدار التجريبي الرابع من Android Q. على الرغم من أن دعم DSU ليس مطلوبًا، إلا أن Google تأمل أن يقوم مصنعو المعدات الأصلية بتمكين الميزة على أي حال لأنها تبسط الاختبار الآمن للتوافق مع Treble. على سبيل المثال، يمكن لمهندس برمجيات OEM وضع GSI على بطاقة SD حتى يتمكنوا من التشغيل بسرعة على أجهزة متعددة لاختبار التوافق مع Treble.
الأمان لتحديثات النظام الديناميكية
نظرًا لأن DSU يقدم نظام تشغيل ثانيًا بشكل أساسي في هذا المزيج، تحتاج Google إلى التأكد من عدم إمكانية التلاعب بهذا التثبيت الجديد لكسر سلامة الجهاز. وهكذا، توجد نفس وسائل الحماية الأمنية الأساسية للتثبيت الأصلي لتثبيت GSI: سياسات التشغيل الذي تم التحقق منه لنظام Android وSELinux. علاوة على ذلك، فإن التطبيقات التي تتمتع بتوقيع INSTALL_DYNAMIC_SYSTEM|الإذن المميز هي وحدها التي يمكنها بدء GSI التثبيت، بينما يمكن للتطبيقات التي لديها إذن التوقيع MANAGE_DYNAMIC_SYSTEM تمكين/تعطيل أو مسح GSI تثبيت. وهذا يعني أن التطبيقات الموثوقة على مستوى النظام فقط هي التي يمكنها العمل مع DSU.
لضمان حماية بيانات المستخدم الأصلية، قامت Google بإضافة آلية حماية إضافية في أندرويد س. مُسَمًّى "نقطة تفتيش"، تحمي الميزة من تدمير بيانات المستخدم عن طريق استعادة الأقسام التي تم فحصها إلى حالتها الأصلية. نقاط التفتيش مفيدة ليس فقط لـ DSU. كما أنها تستخدم للحماية من الأخطاء مشروع الخط الرئيسي وحدة APEX و أ/ب تحديثات عبر الهواء. (الأجهزة التي تحتوي على أقسام A/B تتمتع بالفعل بحماية التراجع، ولكن عمليات التراجع هذه تتطلب إعادة ضبط بيانات المصنع بينما لا تتطلب نقاط التحقق من بيانات المستخدم ذلك.)
تركيب جي اس اي
إذا كان جهازك يدعم DSU مثل سلسلة Pixel 3، فمن السهل تثبيت GSI. عليك أولاً التأكد من تمكين علامة ميزة النظام الديناميكي من خلال إحدى الطريقتين التاليتين:
- إذا كنت تستخدم إصدار userdebug، فقم بتمكين علامة settings_dynamic_android في الإعدادات > النظام > خيارات المطور > علامات الميزات.
- إذا كنت تستخدم إصدار مستخدم، فقم بتشغيل أمر adb Shell التالي:
setproppersist.sys.fflag.override.settings_dynamic_system 1
ثم قم بتنزيل أحدث إصدار من Android Q beta GSI من جوجل أو OEM الخاص بجهازك. (تسمح DSU فقط بتثبيت GSIs الموقعة من Google أو OEM.) بمجرد التنزيل، استخدمها simg2img لتحويل الصورة المتفرقة إلى صورة خام. استخدم gzip لحزم الصورة الأولية، ثم انسخ الأرشيف الناتج إلى موقع على جهازك وحدة تخزين خارجية (على سبيل المثال /data/media/0/Download) أو وسيلة تخزين خارجية فعلية (مثل بطاقة SD الفعلية بطاقة). وأخيرًا، قم بتشغيل تطبيق DynamicSystemInstallationService بالنية الصحيحة لبدء التثبيت:
adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592بمجرد النقر فوق إعادة التشغيل، سيتم التمهيد في GSI. تعتمد سهولة استخدام الجهاز في GSI على مدى جودة تنفيذ الشركة المصنعة لجهازك لـ Treble (أو بالأحرى، مدى قلة انتهاكهم لـ Treble التوافق.) ستعمل بعض الأجهزة بشكل أفضل مع GSIs أكثر من غيرها، ولكن بشكل عام، لا تتوقع استخدام هذا التثبيت كبرنامج يومي سائق. من المفترض أن تختبر تطبيقك ثم تخرج عن طريق إعادة التشغيل. إذا كنت تريد البقاء في تثبيت GSI لإجراء المزيد من الاختبارات، فيمكنك استخدام gsi_tool أمر شل.
يمكن العثور على تعليمات تثبيت GSI الكاملة لـ DSU هنا. يمكن تقديم الأخطاء على أداة تعقب مشكلات جوجل،رديت، أو تجاوز سعة المكدس.
السبب وراء تحديثات النظام الديناميكية
عندما تحدثت إلى إليان مالشيف في Google I/O، كرر ما قاله Hung-ying Tyan من فريق Treble حول الوصول المبكر إلى GSI في قمة تطوير Android لشهر نوفمبر. قدمت جوجل DSU ل التماس ردود الفعل من أكبر عدد ممكن من الجمهور. والهدف هو تحسين نوعية GSI، والتي بدورها يعمل على تحسين جودة إصدار Android المستقبلي نظرًا لأن GSI هو أنقى أشكال Android. تعد Google حاليًا الشركة الوحيدة التي تختبر توافق الإصدار التالي من GSI (على سبيل المثال، مدى جودة عمل صورة نظام Android Q أعلى نظام Android P) تنفيذ البائع)، ولكن مع زيادة عدد الأشخاص الذين يقومون بإصدار GSIs وإبداء الرأي، يمكن لمصنعي المعدات الأصلية إصلاح انتهاكات التوافق الثلاثي بحيث تعمل GSIs بشكل أفضل في مستقبل. يقول إليان إن هناك اهتمامًا قويًا من مصنعي المعدات الأصلية والبائعين مثل Qualcomm بإعادة استخدام صور البائعين من إصدار Android السابق مع صورة نظام الإصدار التالي. تساعد مبادرات مثل DSU Google ومصنعي المعدات الأصلية على سد الفجوة في التغطية من الاختبارات الآلية مثل VTS وCTS-on-GSI. وبالتالي، تحصل Google على المزيد من مختبري النسخة التجريبية لتقديم تعليقات حول إصدار Android التالي، بينما تسمع أيضًا عن انتهاكات التوافق الثلاثي حتى يتمكن مصنعو المعدات الأصلية من تحسين عملهم.
نرحب بإضافة تحديثات النظام الديناميكية في Android Q، ولكنها لن تكون حل التشغيل المزدوج الذي يأمله البعض منكم. كما ذكرنا سابقًا، لا يمكن تثبيت سوى صور النظام الموقعة من Google أو OEM. عندما سألت Iliyan عن إمكانية توسيع DSU لدعم النظام البيئي لنظام Android البديل وقال إنه من الممكن تقنيًا القيام بذلك لأن DSU هي مجرد قناة لتوصيل النظام الصور. يمكن لأي OEM استخدامه كيفما يريد طالما أن النتيجة النهائية متوافقة مع Android. لم تقم Google بإنشاء بديل لنظام OTA هنا، وليس المقصود من DSU أن يتم استخدامه للتشغيل المزدوج الحقيقي. بغض النظر، فإن العمل الذي قامت به Google على Treble يجعل Android أكثر نمطية، لذلك لن أتفاجأ إذا أصبح التشغيل المزدوج الأصلي حقيقة واقعة في المستقبل.