معاينة مطور Android 11: جميع ميزات الخصوصية والأمان الجديدة

قبل الموعد المحدد، جوجل صدر اليوم أول معاينة للمطورين الإصدار التالي من نظام التشغيل Android: Android 11. تتوفر صور النظام لأجهزة Pixel 2 وPixel 3 وPixel 3a وPixel 4، ولكن إذا لم تكن تمتلك واحدة منها الأجهزة، يمكنك أيضًا تجربة معاينة المطور عبر محاكي Android Studio أو النظام العام صورة. على الرغم من أن Google تقوم بحفظ معظم ميزات المستخدم والمطور الجديدة والمثيرة لإعلان كبير في مؤتمر Google I/O 2020، شاركت الشركة عددًا كبيرًا من التغييرات المتوفرة في معاينة المطور الأولى. فيما يلي ملخص لجميع الميزات الجديدة المتعلقة بالخصوصية والأمان التي أعلنت عنها Google في Android 11 Developer Preview 1.

Android 11 Developer Preview 1 - ميزات خصوصية جديدة

الوصول إلى إذن لمرة واحدة

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

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

تغييرات التخزين النطاق

في أندرويد 10 بيتا 2، اقترحت Google تغييرًا جذريًا في الطريقة التي تصل بها التطبيقات إلى وحدة التخزين الخارجية على نظام Android. (يتم تعريف وحدة التخزين الخارجية هنا على أنها البيانات المرئية للمستخدم والتطبيقات الأخرى الموجودة في /data/media.) كان التغيير، الذي أطلق عليه اسم "Scoped Storage"، يهدف إلى القضاء على الاستخدام الواسع النطاق لـ READ_EXTERNAL_STORAGE إذن. كان عدد كبير جدًا من التطبيقات على متجر Google Play يطلب ويمنح حق الوصول إلى وحدة التخزين الخارجية بالكامل حيث كان المستخدمون يحفظون مستنداتهم الخاصة وصورهم ومقاطع الفيديو والملفات الأخرى. باستخدام Scoped Storage، سيتم منح التطبيقات، افتراضيًا، فقط القدرة على رؤية أدلة البيانات الخاصة بها. إذا كان التطبيق يحمل إذن READ_EXTERNAL_STORAGE ضمن تطبيق Scoped Storage، فيمكنه عرض ملفات وسائط معينة يمكن الوصول إليها من خلال MediaStore API. وبدلاً من ذلك، يمكن للتطبيق استخدام Storage Access Framework ليقوم المستخدم بتحديد الملفات يدويًا من خلال منتقي ملفات النظام. وأخيرًا، يمكن للتطبيقات التي تحتاج إلى وصول واسع النطاق إلى وحدة التخزين الخارجية، مثل مديري الملفات، استخدام إطار الوصول إلى التخزين للطلب المستخدم لمنح التطبيق حق الوصول إلى الدليل الجذر لوحدة التخزين الخارجية، وبالتالي منح الوصول إلى جميع الأدلة الفرعية الخاصة به، أيضاً.

تم ضبط تطبيق Scoped Storage ليدخل حيز التنفيذ على جميع التطبيقات في Android 10، ولكن بعد ردود الفعل والانتقادات من المطورين، جوجل استرخاء التغييرات، ولا يتطلبها إلا للتطبيقات التي تستهدف مستوى واجهة برمجة التطبيقات (API) 29 (Android 10). بعد الأول من أغسطس 2020، يجب أن تستهدف جميع التطبيقات الجديدة المقدمة إلى متجر Google Play نظام التشغيل Android 10، وينطبق الشيء نفسه على جميع التحديثات للتطبيقات الحالية بعد الأول من نوفمبر 2020. علاوة على ذلك، في Android 11، مطورو تطبيقات إدارة الملفات يجب تقديم نموذج الإعلان إلى Google للسماح لها بالوصول على نطاق واسع إلى وحدة التخزين الخارجية؛ بمجرد قبولها، سيكون لتطبيقات مدير الملفات عرضًا غير مفلتر لـ MediaStore ولكن لن تتمكن من الوصول إلى أدلة التطبيقات الخارجية.

بالإضافة إلى ذلك، أدخلت Google تغييرات أخرى على Scoped Storage في Android 11 Developer Preview. يمكن للتطبيقات الاشتراك للحصول على مسار الملف الأولي وتنفيذ عمليات التحرير المجمعة لملفات الوسائط في MediaStore. تم تحديث DocumentsUI لتكون أبسط للمستخدمين. تم الإعلان عن هذه التغييرات في قمة تطوير أندرويد العام الماضي، وقد وعدنا بإدخال تحسينات إضافية على Scoped Storage في إصدارات Android 11 المستقبلية.

Android 11 Developer Preview 1 - ميزات أمان جديدة

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

منذ أوائل العام الماضي، عملت جوجل على واجهة برمجة تطبيقات IdentityCredential وHAL في AOSP. تضع هذه الميزة الأساس لتخزين مستندات الهوية بشكل آمن على جهازك المحمول، وعلى وجه الخصوص، رخص القيادة المتنقلة المتوافقة مع ISO 18013-5. جوجل رسميا تم الإعلان عن هذه الميزة في Google I/O 2019والآن أصبح مدعومًا أخيرًا في Android 11 Developer Preview 1.

لم يكن لدى Google الكثير لتقوله حول هذه الميزة في البيان الصحفي، ولكن نظرًا لأنه يتم تطوير الميزة بشكل علني، فنحن نعرف بالفعل الكثير مما تم التخطيط له. في I/O 2019، ذكرت Google أنها تعمل مع ISO لتوحيد تنفيذ جوازات السفر الإلكترونية؛ ما زلنا لا نعرف متى ستكون جوازات السفر الإلكترونية متاحة، ولكن هناك بالفعل العديد من الولايات الأمريكية حيث يتم تنفيذ رخصة القيادة الإلكترونية أو هي في المرحلة التجريبية. وقالت Google أيضًا إنها تعمل على توفير مكتبة Jetpack حتى يتمكن المطورون من إنشاء تطبيقات الهوية. لا نعرف متى سيتمكن المطورون من اختبار هذه الميزة، نظرًا لأن الدعم المناسب يتطلب أجهزة آمنة على الجهاز. ال وحدة المعالجة الآمنة على Qualcomm Snapdragon 865 يدعم IdentityCredential API، على الرغم من أنه قد لا يدعم وضع الوصول المباشر لواجهة برمجة التطبيقات نظرًا لأن وحدة SPU مدمجة في SoC؛ سيسمح وضع الوصول المباشر للمستخدم بسحب معرف إلكتروني مخزن حتى في حالة عدم وجود طاقة كافية لتشغيل Android. لمزيد من المعلومات حول واجهة برمجة التطبيقات هذه، أوصي قراءة التغطية الأولية لدينا حيث قدم شون ويلدن، قائد فريق الأمان المدعوم بأجهزة Android، مدخلاته.

وحدات الخط الرئيسي للمشروع الجديد

كان تقديم أحد أكبر التغييرات في Android 10 للأجهزة التي تم إطلاقها حديثًا مشروع الخط الرئيسي، والذي، على الرغم من اسمه، لا علاقة له بدعم Linux kernel الرئيسي على Android. (هذا المشروع، بالمناسبة، يسمى Generic Kernel Image ولا يزال قيد التنفيذ.) بدلاً من ذلك، الغرض من Project Mainline هو جوجل تنتزع السيطرة على مكونات إطار العمل الرئيسية وتطبيقات النظام بعيدًا عن مصنعي المعدات الأصلية. يتم تغليف كل وحدة Mainline إما بملف APK أو ملف أبيكس ويمكن تحديثه بواسطة Google من خلال متجر Play. يرى المستخدم التحديثات على أنها "تحديث نظام Google Play" (GPSU) على أجهزته، ويتم إصدار التحديثات بإيقاع منتظم كقطار (على سبيل المثال. يتم تنزيلها وتثبيتها في نفس الوقت).

تفرض Google تضمين وحدات Mainline محددة، والتي تضمنت 13 وحدة في وقت Google I/O 2019. الآن، تفرض Google ما مجموعه 20 وحدة رئيسية في Android 11 Developer Preview 1.

*ملاحظة: في وقت النشر، لم تقدم لنا Google القائمة الكاملة لوحدات Mainline المطلوبة حاليًا. سنقوم بتحديث هذا الجدول بمجرد حصولنا على القائمة الكاملة.

التغييرات البيومترية السريعة

تم تقديم نظام Android 9 Pie واجهة برمجة تطبيقات BiometricPrompt، وهي واجهة برمجة تطبيقات موحدة لأجهزة المصادقة البيومترية. توفر واجهة برمجة التطبيقات (API) للمطورين طريقة لتحدي المستخدم من خلال القياسات الحيوية المحفوظة، سواء كانت بصمة الإصبع أو الوجه أو قزحية العين. قبل BiometricPrompt، كان على المطورين إنشاء مربع حوار المصادقة الخاص بهم واستخدام واجهة برمجة تطبيقات FingerprintManager، التي تدعم فقط مصادقة بصمات الأصابع، لتحدي المستخدم. في هواتف Galaxy الذكية المزودة بماسحات ضوئية لقزحية العين، كان على المطورين استخدام SDK من سامسونج لتحدي المستخدم. باستخدام BiometricPrompt، يمكن للمطورين تحدي المستخدم بأي طريقة بيومترية مدعومة، ويوفر النظام مربع الحوار للمستخدم. وبالتالي، لم يعد المطورون بحاجة إلى القلق بشأن توفير الدعم على وجه التحديد لنوع معين من أجهزة القياسات الحيوية، ولم يعد عليهم أيضًا ترميز واجهة المستخدم لمربع حوار المصادقة. ال أجهزة التعرف على الوجه الآمنة في Pixel 4، على سبيل المثال، يمكن استخدامه للمصادقة في التطبيقات التي تستخدم BiometricPrompt.

ما الجديد في BiometricPrompt في Android 11 Developer Preview 1؟ أضافت Google ثلاثة أنواع جديدة من أدوات المصادقة: بيانات اعتماد قوية وضعيفة وبيانات اعتماد الجهاز. قبل Android 11، لم يكن بإمكان المطورين سوى الاستعلام عن الأجهزة البيومترية الآمنة للجهاز — الماسح الضوئي لبصمات الأصابع، أو الماسح الضوئي للتعرف على الوجه ثلاثي الأبعاد، أو الماسح الضوئي لقزحية العين — عند استخدام BiometricPrompt. بدءًا من Android 11 Developer Preview 1، يمكن للمطورين أيضًا الاستعلام عن طرق القياسات الحيوية التي تعتبر "ضعيفة" مثل حلول التعرف على الوجه القائمة على البرامج والموجودة في العديد من الهواتف. على سبيل المثال، جوجل تم إدراج العديد من هواتف Samsung Galaxy في القائمة السوداء سابقًا لإعادة أداة مصادقة ضعيفة للتعرف على الوجه عند محاولة المصادقة المستندة إلى التشفير. الأمر الآن متروك للمطور لتحديد مستوى دقة المصادقة البيومترية التي يحتاجها تطبيقه.

التخزين الآمن ومشاركة BLOBs

ستجعل واجهة برمجة التطبيقات الجديدة التي تسمى BlobstoreManager من الأسهل والأكثر أمانًا للتطبيقات مشاركة البيانات الثنائية الكبيرة مع بعضها البعض. تستشهد Google بنماذج التعلم الآلي التي تشارك التطبيقات كحالة استخدام مثالية لواجهة برمجة تطبيقات BlobstoreManager الجديدة.

تصلب المنصة

في محاولة لتقليل سطح الهجوم على Android، تستخدم Google معقمات LLVM لتحديد "أخطاء إساءة استخدام الذاكرة والسلوك غير المحدد الذي يحتمل أن يكون خطيرًا." تعمل Google الآن على توسيع نطاق استخدام هذه العناصر المطهرات القائمة على المترجم للعديد من المكونات الأمنية الهامة بما في ذلك BoundSan، وIntSan، وCFI، وShadow-Call Stack. لحل مشكلات الذاكرة في الإنتاج، تعمل Google على تمكين "وضع علامات على مؤشر الكومة" لجميع التطبيقات التي تستهدف Android 11 أو الإصدارات الأحدث. يتم دعم علامات مؤشر الكومة على أجهزة ARMv8 64 بت مع دعم kernel لتجاهل ARM Top-byte (TBI)، وهي ميزة يتم من خلالها " تتجاهل الأجهزة البايت العلوي للمؤشر عند الوصول إلى الذاكرة "تعطل التطبيقات القابلة للتكرار/التكرار على السطح بشكل أكبر"، لذلك يجب على المطورين اختبار تطبيقاتهم بدقة على Android 11 Developer الجديد معاينة. من أجل العثور على العديد من أخطاء الذاكرة في النظام وإصلاحها، استخدمت Google أداة للكشف عن أخطاء الذاكرة تسمى AddressSanitizer بمساعدة الأجهزة (هواسان). تقدم Google صورًا للنظام تم إنشاؤها مسبقًا وممكّنة لـ HWASan على خادم بناء AOSP في حال كنت مهتمًا بالعثور على أخطاء الذاكرة وإصلاحها في تطبيقاتك الخاصة.

---

من المؤكد أن جوجل ستعلن عن ميزات إضافية لحماية خصوصية المستخدم وتحسين الأمان، لذا تأكد من متابعة تغطية Android 11 لتبقى على اطلاع دائم.

أخبار Android 11 على XDA