حصريًا: 3 من أفضل ميزات Android 11 لن تكون متاحة على كل الأجهزة

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

لفهم كيف يكون ذلك ممكنًا، علينا أن نشرح بإيجاز كيفية توزيع نظام التشغيل Android من Google إلى صانعي أجهزة الهواتف الذكية. الروبوت هو نظام تشغيل مفتوح المصدر مرخص بموجب Apache 2.0، مما يعني أن أي شخص، بدءًا من المطورين المستقلين وحتى الشركات الكبرى، يتمتع بالحرية في تعديل نظام التشغيل وتوزيعه على أجهزته الخاصة. ستكون معظم ميزات نظام التشغيل الجديدة التي كشفت عنها Google لنظام Android 11 جزءًا من مشروع Android مفتوح المصدر (AOSP) الذي يستخدمه الهاتف الذكي. يعتمد صانعو الأجهزة على برامجهم الخاصة، لكن ترخيص Apache 2.0، كما ذكرت من قبل، يسمح لأي شخص بتعديل البرنامج كما يراه ملائم. من أجل الحفاظ على الاتساق في واجهات برمجة التطبيقات وسلوك النظام الأساسي بين أجهزة Android، تقوم Google بتوزيع خدمات Google Mobile Services (والتي تتضمن التطبيقات والأطر مثل متجر Google Play وخدمات Google Play) مع اتفاقيات ترخيص تلزم الأجهزة بالالتزام بالقواعد بموجب شروط Google "

برنامج التوافق مع الاندرويد"(من بين متطلبات أخرى). يتكون برنامج توافق Android من مجموعات اختبار آلية متعددة ومجموعة من القواعد المذكورة في Android وثيقة تعريف التوافق (CDD).

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

لن يتم نشر Android 11 CDD إلا في وقت لاحق من هذا العام، على الأرجح في أوائل سبتمبر. لكن المطور @com.deletescape شاركنا نسخة ما قبل النشر من مستند يعرض تفاصيل التغييرات القادمة على CDD، مما يمنحنا نظرة مبكرة على كيفية تشكيل Google لنظام Android 11 عبر النظام البيئي. الغالبية العظمى من التغييرات التي يزيد عددها عن 60 تغييرًا على CDD ليست مثيرة للاهتمام جدًا للمستخدمين - فهي تصف كيفية القيام بذلك يتعين على صانعي الأجهزة تنفيذ واجهات برمجة التطبيقات (APIs) معينة، والإعلان عن ميزات معينة، وتنفيذ نواة معينة سمات. ومع ذلك، لفتت انتباهنا 3 من التغييرات التي تم إجراؤها على CDD لأنها تتعلق ببعض الميزات الأكثر إثارة للاهتمام في Android 11. وهنا ما كشفنا.

ضوابط الجهاز

عناصر التحكم في الجهاز هي ميزة في Android 11 تسمح بإظهار عناصر التحكم في التشغيل الآلي للمنزل الذكي في قائمة الطاقة. يمكنك إطفاء الأضواء، وفتح باب الجراج، وتشغيل المكنسة الكهربائية، وتغيير درجة حرارة منزلك، والقيام بالمزيد دون فتح عشرات التطبيقات المنزلية الذكية المختلفة. أضافت Google واجهات برمجة التطبيقات التي يمكن لمطوري تطبيقات المنزل الذكي استخدامها لعرض عناصر التحكم في قائمة الطاقة. نعتقد أن هذه ميزة رائعة أخيرًا يجلب هاتفك الذكي إلى المنزل الذكي. ولسوء الحظ، ليس هناك حاجة لمصنعي المعدات الأصلية لتنفيذه فعليًا. إذا اعتقد أحد مصنعي المعدات الأصلية (OEM) أن الميزة ضعيفة أو أنهم يريدون اتباع مسار مختلف (مثل السماح فقط بـ Smart عناصر التحكم المنزلية من الأجهزة الموجودة في النظام البيئي الخاص بهم)، فيمكنهم ببساطة تعطيل الدعم للجهاز ضوابط.

عندما أضافت Google لأول مرة عناصر التحكم في الجهاز إلى CDD في 25 فبراير 2020، فقد فرضت إدراجها عن طريق إضافة متطلب "MUST" في القسم 2.2.3 - متطلبات البرامج المحمولة. ومع ذلك، في 20 مايو 2020، قامت Google بتحديث النص لإزالة عبارة "MUST" المقترحة. يوضح القسم الجديد 3.8.16 - عناصر التحكم في الجهاز كيفية تنفيذ الميزة ولكنه لا يتطلب تنفيذها في المقام الأول! نأمل ألا يقوم مصنعو المعدات الأصلية بتعطيل هذه الميزة الرائعة، ولكن لا توجد طريقة لنا لمعرفة ما إذا كانوا قد قاموا بتعطيلها حتى يتم ذلك على استعداد للكشف عن نكهاتهم الخاصة من Android المبنية على Android 11، وهو ما لن يحدث إلا بعد عدة أشهر الآن.

القسم المقترح 3.8.16 (جديد) - عناصر التحكم في الجهاز (تم التحديث بتاريخ 20/5/2020)

3.8.16 عناصر التحكم في الجهاز

يشتمل Android على ControlsProviderService وواجهات برمجة تطبيقات التحكم للسماح للمطورين بنشر عناصر التحكم في الجهاز للحصول على حالة سريعة وإجراءات للمستخدمين.

3.8.16.1 يتحكم الجهاز في قدرة المستخدم على تحمل التكاليف

إذا قامت الأجهزة بتنفيذ عناصر التحكم في الجهاز، فإنها:

• [C-1-1] يجب الإبلاغ عن علامة android.software.controls.feature لتكون TRUE
• [C-1-2] يجب أن يوفر للمستخدم القدرة على إضافة مفضلات المستخدم وتحريرها وتحديدها وتشغيلها من عناصر التحكم المسجلة بواسطة تطبيقات الطرف الثالث من خلال android.service.controls. ControlsProviderService وandroid.service.controls. واجهات برمجة التطبيقات للتحكم.
• [C-1-3] يجب أن يوفر الوصول إلى إمكانيات المستخدم هذه خلال ثلاثة تفاعلات من المشغل
• [C-1-4] يجب أن يعرض بدقة في هذا المستخدم اسم ورمز كل تطبيق تابع لجهة خارجية يوفر عناصر تحكم عبر android.service.controls. واجهة برمجة تطبيقات ControlsProviderService بالإضافة إلى أي رمز محدد ونص الحالة ونوع الجهاز والاسم والبنية والمنطقة واللون المخصص والعنوان الفرعي المقدم من android.service.controls. واجهة برمجة تطبيقات التحكم

على العكس من ذلك، إذا لم تقم تطبيقات الجهاز بتنفيذ مثل هذه الضوابط، فإنها

• [C-2-1] يجب الإبلاغ عن القيمة Null لـ ControlsProviderService وControl APIs.

اقرأ أكثر

المحادثات في الإخطارات

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

التغييرات المقترحة على القسم 3.8.3.1 - تقديم الإخطارات (تم التحديث بتاريخ 08/04/2020)

إذا كانت تطبيقات الأجهزة تسمح لتطبيقات الجهات الخارجية بإعلام المستخدمين بالأحداث البارزة، فإنها:

...

يقدم Android R دعمًا لإشعارات المحادثة، وهو إشعار يستخدم NotificationManager. يوفر messageStyle معرف اختصار الأشخاص المنشور.

تطبيقات الجهاز هي:

• [H-SR] يوصى بشدة بتجميع وعرض إشعارات المحادثة قبل عدم المحادثة الإخطارات باستثناء إشعارات الخدمة الأمامية المستمرة وأهميتها: عالية إشعارات.

إذا تم تجميع إشعارات المحادثة في قسم منفصل، فسيتم استخدام تطبيقات الجهاز

• [H-1-8] يجب عرض إشعارات المحادثة قبل الإشعارات غير المتعلقة بالمحادثة باستثناء إشعارات الخدمة الأمامية المستمرة والأهمية: الإشعارات العالية.

تطبيقات الجهاز هي:

• [H-SR] يوصى بشدة بتوفير الوصول إلى الإجراءات التالية من إشعارات المحادثة: اعرض هذه المحادثة كفقاعة إذا كان التطبيق يوفر البيانات المطلوبة للفقاعات

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

اقرأ أكثر

IdentityCredential - تراخيص القيادة المتنقلة

أخيرًا، إحدى الميزات التي تثير اهتمامي كثيرًا هي واجهة برمجة تطبيقات IdentityCredential. كما وضحنا بالتفصيل العام الماضي، تم تصميم IdentityCredential API للسماح للتطبيقات بتخزين مستندات الهوية، مثل رخص القيادة المتنقلة، على الجهاز. تسمح العديد من البلدان (وبعض الولايات الأمريكية) حول العالم لمواطنيها بالفعل بتخزين رخص القيادة الخاصة بهم في تطبيق جوال. ومع ذلك، تعمل Google على جعل هذا الأمر أكثر أمانًا من خلال تخزين البيانات دون الاتصال بالإنترنت في بيئة آمنة.

يتضمن الكود المصدري لنظام Android 11 واجهة برمجة تطبيقات IdentityCredential (التي سيتصل بها المطورون لتخزين مستندات الهوية في ذاكرة الهاتف). بيئة آمنة) وIdentityCredential HAL (التي تتفاعل مع البيئة الآمنة للهاتف)، ولكن ليس مطلوبًا من مصنعي المعدات الأصلية تنفيذها. عندما اقترحت Google لأول مرة إدراج IdentityCredential في CDD في 10 يناير 2020، فقد أدرجته كمتطلب. ومع ذلك، فقد خففوا هذا المطلب في 18 مارس 2020، ويوصون الآن بشدة بأن يدعم مصنعو المعدات الأصلية هذه الميزة. لا نتفاجأ بأن Google خففت هذا المطلب — فإضافة تغيير يؤثر على بيئة التنفيذ الموثوقة سيتطلب جهدًا من الشركات المصنعة للمعدات الأصلية لتنفيذه. من الممكن أن يحتاج مصنعو المعدات الأصلية ببساطة إلى مزيد من الوقت للاستعداد لهذا التغيير. بالنسبة للمستخدمين، هذا يعني أنه لا يوجد ضمان بأن هاتفك الذكي الذي يعمل بنظام Android 11 سيدعم تخزين رخصة القيادة المحمولة بشكل آمن في بيئة الهاتف الآمنة.

تجدر الإشارة إلى أنه لا توجد قيود فنية تمنع الاعتماد على نطاق واسع لنظام IdentityCredential بين أجهزة Android 11. أحد متطلبات تنفيذ نظام IdentityCredential هو أن الجهاز لديه تنفيذ موثوق به البيئة (TEE) أو معالج آمن مخصص يتفاعل فيه "التطبيق الموثوق" مع الهوية المخزنة وثائق. منذ إصدار Android 7.0 Nougat، طلبت Google من جميع أجهزة Android الحديثة دعم "بيئة تنفيذ معزولة" (حسب القسم 2.2.5 - نموذج الأمان في CDD). تتميز الأجهزة المزودة بمعالجات ARM عادةً بمعالجات ARM منطقة الثقة TEE، وتوفر Google نظام تشغيل موثوق الذي يعمل على TrustZone. يعد وجود TEE كافيًا لدعم نظام IdentityCredential، على الرغم من أنه سيكون أكثر أمانًا إذا تم تخزين بيانات الاعتماد في وحدة المعالجة المركزية الآمنة المضمنة (كما هو الحال في وحدة المعالجة الآمنة لبعض معالجات Qualcomm Snapdragon) أو وحدة معالجة مركزية آمنة ومنفصلة (مثل in جوجل تيتان م أو شرائح الأمان الجديدة من سامسونج). والجدير بالذكر أن الأجهزة ذات وحدات المعالجة المركزية الآمنة المنفصلة قد تكون أيضًا قادرة على دعم ميزة "وضع الوصول المباشر" لنظام IdentityCredential، والذي سيسمح للمستخدم بسحب مستند الهوية الخاص به حتى في حالة عدم وجود طاقة كافية متبقية في الجهاز لتشغيل نظام التشغيل الرئيسي.

القسم المقترح 9.11.3 (جديد) - بيانات اعتماد الهوية (تم التحديث بتاريخ 18/3/2020)

يسمح نظام بيانات اعتماد الهوية لمطوري التطبيقات بتخزين واسترجاع مستندات هوية المستخدم.

تطبيقات الجهاز:

• يوصى بشدة بـ [C-SR] لتنفيذ نظام بيانات اعتماد الهوية.

إذا كانت تطبيقات الأجهزة تنفذ نظام بيانات اعتماد الهوية، فإنها:

• [C-0-1] يجب أن يُرجع قيمة غير فارغة لـ IdentityCredentialStore#getInstance() طريقة.
• [C-0-2] يجب تنفيذ واجهات برمجة التطبيقات `android.security.identity.*` مع رمز يتواصل مع جهة موثوقة تطبيق يعمل إما في بيئة تنفيذ موثوقة (TEE) أو على نظام آمن مخصص المعالج. يجب تنفيذ التطبيق الموثوق به بحيث يكون قاعدة حوسبة موثوقة لنظام بيانات اعتماد الهوية لا يتضمن نظام التشغيل Android.

اقرأ أكثر

تعمل Google أيضًا على مكتبة IdentityCredential Jetpack لتسهيل قيام المطورين بإضافة دعم لتخزين الهوية بشكل آمن المستندات على Android، ولكن التحدي الحقيقي هو إقناع الحكومات بالسماح للتطبيقات باستخدام واجهة برمجة التطبيقات هذه لتخزين المعرفات الحكومية بشكل آمن. وفق إنجادجيت، طرحت كوريا الجنوبية للتو دعمًا لتخزين رخص القيادة في تطبيق جوال، لذلك بدأنا نشهد زيادة طفيفة في قبول هذه التقنية. أنا، شخصيًا، متحمس لرؤية أين سيصل هذا لأنه سيعني شيئًا أقل لأحمله معي عندما أخرج.

---

الوثيقة التي حصلنا عليها تدرج التغييرات التي تم إجراؤها على العناية الواجبة بحلول تاريخ إجراء هذه التغييرات. تم إجراء آخر التغييرات في 10 يونيو 2020، مما يعني أن المستند الذي لدينا محدث إلى حد ما. من المحتمل أن تتراجع Google عن هذه التغييرات وتجعلها جميع المتطلبات مرة أخرى قبل الإصدار العام لنظام Android 11، ولكننا نشك في أن Google ستقوم فجأة بإجراء CDD أكثر صارم. من المحتمل أن تكون هذه التغييرات قد تم تخفيفها بسبب التعليقات الواردة من مصنعي المعدات الأصلية الذين سيتعين عليهم العودة وتنفيذ هذه الميزات إذا لم يكونوا مخططين بالفعل للقيام بذلك. يستغرق ذلك وقتًا وجهدًا ومالًا، مما سيؤدي إلى تأخير إصدار Android 11 للأجهزة غير التابعة لشركة Google بشكل أكبر. ومع ذلك، إذا قامت Google بجعل هذه الميزات مطلوبة مرة أخرى، فسنقوم بنشر تحديث على بوابة XDA.