Android 11 AMA: لا توجد لقطات شاشة قابلة للتمرير، وتشغيل أسرع للتطبيقات، والمزيد

بالأمس، أصدرت جوجل أندرويد 11 بيتا 2، مما يوفر SDK وNDK النهائية والأسطح المواجهة للتطبيقات وسلوكيات النظام الأساسي والقيود المفروضة على الواجهات غير SDK للمطورين. اليوم، تجيب Google على الأسئلة المتعلقة بنظام Android 11 على مجتمع Reddit /r/AndroidDev بعد طرح الأسئلة الأسبوع الماضي. فيما يلي ملخص لكل ما تعلمناه من AMA من Google (اسألني أي شيء).

لن تكون إحدى ميزات Android 11 الأكثر توقعًا متاحة عند تشغيل نظام التشغيل سيخرج من النسخة التجريبية في 8 سبتمبر: التمرير لقطات الشاشة. بدءًا المخطط إطلاقه في Android 11، أكدت Google الآن أن الميزة "لم يتم تخصيصها لـ R." معاينة مطور Android 11 1 و تحتوي جميع إصدارات DP وBeta اللاحقة على زر نائب لالتقاط لقطة شاشة قابلة للتمرير ظهرت يدويًا باستخدام أمر مطور مخفي، ولكن النقر على الزر يظهر ببساطة رسالة نخب تفيد بأن الميزة "لم يتم تنفيذها".

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

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

لأنه كان على الفريق "تركيز موارده المحدودة"، خاصة بسبب التحديات التي نشأت بواسطة COVID-19، قرر الفريق وضع لقطات شاشة قابلة للتمرير في الخلفية لإصدار Android مستقبلي.

متطلبات CDD الجديدة لإبلاغ المستخدمين بقيود الخلفية

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

بغض النظر، يشعر العديد من مطوري التطبيقات بالإحباط بشكل مفهوم بسبب هذه التعديلات على سلوك نظام Android الأساسي، مما أدى إلى دفع المطورين للتعليق يسألون Google عما يفعلونه حيال ذلك إلى الجزء العلوي من Reddit AMA. إليك رد جوجل:

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

إذا نفذت تطبيقات الجهاز آلية خاصة لتقييد التطبيقات وكانت هذه الآلية أكثر تقييدًا من مجموعة الاستعداد "النادرة" في AOSP، فإنها:

[C-1-5] يجب إبلاغ المستخدمين إذا تم تطبيق قيود التطبيق على التطبيق تلقائيًا. (جديد) يجب عدم تقديم هذه المعلومات قبل 24 ساعة من تطبيق هذه القيود.

(ملاحظة) يعتبر الإيقاف القسري أكثر تقييدًا من "نادر" ويجب أن يتوافق مع جميع المتطلبات بموجب 3.5.1، بما في ذلك 3.5.1/C-1-5 الجديدة

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

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

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

تحسين النسخ الاحتياطية من جهاز إلى جهاز

في الشهر الماضي، اكتشفنا تغييرًا في وثائق Android 11 ألمح إلى دعم النسخ الاحتياطية للبيانات المحلية بشكل أفضل. في Android 11، سيتجاهل النظام سمة LetBackup Manifest لأي تطبيق يستهدف مستوى واجهة برمجة التطبيقات (API) 30 عندما يبدأ المستخدم عملية ترحيل "من جهاز إلى جهاز" لملفات التطبيق. يقول موظف Google إليوت ستوك إن هذه الميزة تهدف إلى "تسهيل الأمر على الشركات المصنعة للهواتف لإنشاء أدوات الترحيل من جهاز إلى جهاز" مثل "منتج Smart Switch الممتاز من سامسونج" المساعدة في "ضمان نقل التطبيقات بشكل أكثر موثوقية بين الأجهزة من منظور المستخدم." للأسف، لا ينطبق هذا على النسخ الاحتياطية السحابية، حيث تريد Google "منح مطوري البرامج التحكم في ما يحدث مع بيانات تطبيقاتهم." وعلى هذا النحو، سيظل نظام التشغيل Android 11 يحترم سمةallowBackup لأي نسخ احتياطي واستعادة قائم على السحابة، مثل Google Drive المدمج في خدمة Google Play. دعم. وأخيرًا، تعترف جوجل بأن الحد الأقصى للنسخ الاحتياطي البالغ 25 ميجابايت لكل تطبيق قد لا يكون كافيًا لبعض المطورين، لذلك يبحثون عن طرق لحل هذه المشكلة. ومع ذلك، فإن النسخ الاحتياطية المحلية على جهاز الكمبيوتر ليست قيد النظر، وتكرر Google خطتها للقيام بذلك التخلص التدريجي من النسخ الاحتياطي لبنك التنمية الآسيوي في إصدار Android المستقبلي.

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

سرعات بدء تشغيل أسرع للتطبيقات من خلال عملية القراءة المسبقة للإدخال/الإخراج (IORap)

تقوم Google دائمًا بتجربة طرق لتحسين الأداء في Android. إحدى الميزات غير المعروفة التي أضافوها في Android 10 تسمى مجموعة عمليات التطبيقات غير المتخصصة (USAP). تعمل هذه الميزة على إلغاء تفرع Zygote أثناء عملية بدء تشغيل التطبيق، مما يوفر حوالي 5 مللي ثانية تقريبًا في متوسط ​​سرعات بدء تشغيل التطبيق على جهاز Pixel 2. الميزة حاليا تم تعطيله افتراضيًا في AOSP، وتوضح Google أن استخدام الذاكرة المضافة لا يزال بحاجة إلى الاختبار. لكن الأمر الأكثر إثارة للاهتمام هو ميزة جديدة قادمة إلى Android 11 تسمى I/O Read Ahead Process (IORap). وفقا لجوجل، ستؤدي هذه الميزة إلى "تأسيس شركات ناشئة باردة أسرع بنسبة تزيد عن 5% مع وصول الحالات البطلة بشكل أسرع بنسبة 20%." هذه الميزة "سيقوم بجلب عناصر التطبيقات مسبقًا (مثل التعليمات البرمجية والموارد) أثناء عملية بدء التشغيل" لتعزيز تشغيل التطبيق سرعات.

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

تغييرات التخزين ذات النطاق في Android 11 - لماذا يتم تقييد الوصول إلى/التنزيلات؟

التطبيقات التي تستهدف Android 11 وتستخدم غرض ACTION_OPEN_DOCUMENT_TREE لطلب الوصول إلى أدلة محددة على الجهاز الخارجي لن تتمكن وحدة التخزين بعد الآن من مطالبة المستخدمين بالوصول إلى الدليل الجذر لوحدة التخزين الخارجية (/data/media/{user})، وتنزيل الدليل (/data/media{user}/Download)، أو أي من أدلة البيانات الخاصة بالتطبيق على وحدة التخزين الخارجية (/Android/data أو /Android/obb). لماذا يتم تقييد الوصول إلى دليل التنزيل؟ بحسب جوجل روكسانا علي آباديذلك لأن مجلد التنزيل "هو الأكثر عرضة لخطر الحصول على معلومات خاصة". على سبيل المثال، المستخدمين الذين يقومون بتحميل الضرائب الخاصة بهم لا ينبغي أن تقلق العوائد أو البيانات المصرفية بشأن احتمال إساءة استخدام التطبيقات لوصولها المستمر للقراءة إلى الدليل. تقول Google إن منتقي المستندات سيكون به "نص محدث... للإشارة إلى أن Android قام بتقييد مجلدات معينة سيتم تحديده." نأمل أن يؤدي هذا إلى تقليل الارتباك حول سبب عدم تمكنهم من منح التطبيقات حق الوصول إلى أدلة معينة أي أكثر من ذلك.

لمزيد من المعلومات حول التغييرات القادمة في سياسة Scoped Storage and Play، الرجوع إلى هذه المقالة.

مواضيع متنوعة

• موقف جوجل بشأن التجذير/التعديل
  • يكرر جيف بيلي من فريق AOSP في Google موقف الشركة بشأن دعم الاختيار. ستواصل Google "التأكد من إمكانية تعديل/تأصيل خط أجهزة Pixel"، ولكنها ستدعم أيضًا "اختيار مصنعي المعدات الأصلية لعدم السماح لأجهزتهم علاوة على ذلك، تمنح Google مطوري البرامج خيار "عدم السماح لبرامجهم بالعمل على الأجهزة التي تم الوصول إلى جذرها"، في إشارة إلى التغييرات الأخيرة في اكتشاف التلاعب بالبرمجيات في واجهة برمجة تطبيقات SafetyNet Attestation API.
• ماذا حدث لـ "الفتح والضبط على الوضع الافتراضي"؟
  • تم صنع اندرويد 10 من المزعج بعض الشيء تعيين تطبيق ما باعتباره المعالج الافتراضي لروابط محددة، والتي تقول جوجل إنها تم إجراؤها لحماية المستخدمين من "التطبيقات الاستغلالية". جوجل تراجعت على هذا التغيير بعد إعادة التفكير فيه، وإجراء "عدد من التغييرات خلف الكواليس" لحماية المستخدم.
• هل تستخدم واجهة برمجة تطبيقات Vulkan Graphics لعرض واجهة المستخدم؟
  • جوجل تخطط في نهاية المطاف لاستخدام واجهة برمجة تطبيقات Vulkan Graphics API لتقديم واجهة المستخدم، مما سيؤدي إلى بعض التحسينات في الأداء. هذا هو لا يزال قيد التقييم، لكن الشركة لم يكن لديها أي تفاصيل لمشاركتها.
• خدمة CallScreeningService مفقودة على العديد من الأجهزة
  • يمكن لتطبيقات Android تنفيذ واجهة برمجة تطبيقات خدمة CallScreeningService لاعتراض المكالمات الواردة والصادرة الجديدة، مما يسمح لهم بالتعرف على المتصل وقبول المكالمة أو رفضها. على الرغم من أن هذه واجهة برمجة تطبيقات موثقة رسميًا، إلا أنه يبدو أن هناك العديد من مصنعي المعدات الأصلية الذين لا يقومون بتنفيذها بشكل صحيح، وفقًا للمطور /u/_صفر مود_. جوجل يؤكد أنه تم التحقق من صحة واجهة برمجة التطبيقات (API) هذه من خلال مجموعة اختبار التوافق (CTS)، وهي مجموعة اختبار تلقائية يجب على جميع الأجهزة اجتيازها حتى تعتبر متوافقة مع Android. لأي سبب من الأسباب، تُرجع واجهة برمجة التطبيقات هذه قيمة فارغة عند استدعائها على أجهزة من مصنعي المعدات الأصلية مثل Huawei أو Vivo أو Xiaomi أو Samsung، لذلك من المحتمل أن يكون لدى مصنعي المعدات الأصلية خطأ في برامجهم.
• لا توجد خطط لإطار البرنامج المساعد الصوتي
  • سأل أحد المطورين شركة Google عما إذا كانوا يخططون لتنفيذ إطار عمل مكون صوتي إضافي مثل وحدات الصوت من Apple، ولكن الاجابة هو أنه من غير المرجح أن يحدث في المستقبل القريب.

يمكنك قراءة جميع الإجابات من فريق هندسة Android هنا. يتحدث الفريق قليلاً عن Java وKotlin ونظام إنشاء Android وCameraX API ومواضيع أخرى في بعض التعليقات. هناك أيضًا العديد من التعليقات حول Wear OS وAndroid TV وAndroid Auto، لكن جوجل تكرر ذلك في الغالب عملهم الحالي على هذه الأنظمة الأساسية ويطلب من المطورين متابعة المزيد من المعلومات أثناء "أندرويد خارج نطاق الهواتف"الأسبوع الذي يبدأ في 10 أغسطس.