إعداد تطبيقك لتغييرات إمكانية تغيير الحجم والاتجاه في Android 17

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

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

مع إطلاق الإصدار التجريبي من Android 17، ننتقل إلى المرحلة التالية من خارطة الطريق التكيّفية: يزيل Android 17 (المستوى 37 لواجهة برمجة التطبيقات) خيار إيقاف التغييرات للمطوّرين فيما يتعلق بقيود الاتجاه وإمكانية تغيير الحجم على الأجهزة ذات الشاشات الكبيرة (أقل عرض يساوي 600 وحدة بكسل مستقلة الكثافة أو أكثر). عند استهداف المستوى 37 لواجهة برمجة التطبيقات، يجب أن يكون تطبيقك قادرًا على التكيّف مع مجموعة متنوعة من أحجام العرض.

تضمن التغييرات في السلوك أن تقدّم منظومة Android المتكاملة تجربة متّسقة وعالية الجودة على جميع عوامل شكل الأجهزة.

التغييرات في Android 17

يجب أن تضمن التطبيقات التي تستهدف Android 17 توافقها مع إيقاف سمات ملف البيان وواجهات برمجة التطبيقات في وقت التشغيل التي تم طرحها في Android 16. ندرك أنّ هذا قد يكون عملية نقل كبيرة لبعض التطبيقات، لذا أدرجنا أفضل الممارسات والأدوات للمساعدة في تجنُّب المشاكل الشائعة لاحقًا في مشاركة المدونة هذه.

لم يتم إدخال أي تغييرات جديدة منذ Android 16، ولم يعُد خيار إيقاف التغييرات للمطوّرين متاحًا. للتذكير: عندما يتم تشغيل تطبيقك على شاشة كبيرة، حيث يعني مصطلح شاشة كبيرة أنّ البُعد الأصغر للشاشة أكبر من 600 وحدة بكسل مستقلة الكثافة أو يساويها، يتم تجاهل سمات ملف البيان وواجهات برمجة التطبيقات التالية:

ملاحظة: كما ذكرنا سابقًا في Android 16، لا تسري هذه التغييرات على الشاشات التي يقل عرضها عن 600 وحدة بكسل مستقلة الكثافة أو التطبيقات المصنّفة كألعاب استنادًا إلى العلامة android:appCategory. 

يحتفظ المستخدمون أيضًا بإمكانية التحكّم. في إعدادات نسبة العرض إلى الارتفاع، يمكن للمستخدمين الموافقة صراحةً على استخدام السلوك المطلوب للتطبيق.

إعداد تطبيقك

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

اختبار تطبيقك

الخطوة الأولى هي اختبار تطبيقك باستخدام هذه التغييرات للتأكّد من أنّه يعمل بشكل جيد على أحجام العرض المختلفة.

استخدِم الإصدار التجريبي 1 من Android 17 مع محاكيات سلسلة Pixel Tablet وPixel Fold في استوديو Android، واضبط targetSdkPreview = “CinnamonBun”. بدلاً من ذلك، يمكنك استخدام اختبار توافق التطبيقات من خلال تفعيل العلامة UNIVERSAL_RESIZABLE_BY_DEFAULT إذا كان تطبيقك لا يستهدف المستوى 36 لواجهة برمجة التطبيقات بعد.

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

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

لنلقِ نظرة على بعض الاستراتيجيات لمعالجة هذه المشاكل الشائعة.

ضمان توافق الكاميرا

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

تأكَّد من أنّ معاينة الكاميرا ليست ممدودة أو تم تدويرها.

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

لضمان تكيّف معاينة الكاميرا بشكل صحيح مع أي حجم للنافذة أو اتجاه، ننصحك باتّباع هذه الحلول الأربعة:

الحلّ 1: Jetpack CameraX (الحلّ المفضّل) 

الحلّ الأبسط والأكثر فعالية هو استخدام مكتبة Jetpack CameraX. تم تصميم عنصر واجهة المستخدم PreviewView لمعالجة جميع تعقيدات المعاينة تلقائيًا:

• يتم تعديل PreviewView بشكل صحيح ليتناسب مع اتجاه المستشعر وتدوير الجهاز والتحجيم
• تحافظ PreviewView على نسبة العرض إلى الارتفاع لصورة الكاميرا، عادةً من خلال التوسيط والاقتصاص (FILL_CENTER)
• يمكنك ضبط نوع المقياس على FIT_CENTER لإضافة شريط أسود إلى المعاينة إذا لزم الأمر

لمزيد من المعلومات، يُرجى الاطّلاع على مقالة تنفيذ معاينة في مستندات CameraX.

الحلّ 2: CameraViewfinder 

إذا كنت تستخدم قاعدة رموز برمجية حالية لـ Camera2، فإنّ مكتبة CameraViewfinder (المتوافقة مع الأنظمة القديمة حتى مستوى واجهة برمجة التطبيقات 21) هي حلّ حديث آخر. تسهّل هذه المكتبة عرض بيانات الكاميرا من خلال استخدام TextureView أو SurfaceView وتطبيق جميع عمليات التحويل اللازمة (نسبة العرض إلى الارتفاع والمقياس والتدوير) نيابةً عنك.

لمزيد من المعلومات، يُرجى الاطّلاع على مشاركة المدونة تقديم Camera Viewfinder ودليل المطوّرين معاينة الكاميرا.

الحلّ 3: تنفيذ Camera2 يدويًا 

إذا لم تتمكّن من استخدام CameraX أو CameraViewfinder، عليك حساب الاتجاه ونسبة العرض إلى الارتفاع يدويًا والتأكّد من تعديل الحسابات عند كل تغيير في الإعدادات:

• احصل على اتجاه مستشعر الكاميرا (على سبيل المثال، 0 أو 90 أو 180 أو 270 درجة) من CameraCharacteristics
• احصل على تدوير العرض الحالي للجهاز (على سبيل المثال، 0 أو 90 أو 180 أو 270 درجة)
• استخدِم قيم اتجاه مستشعر الكاميرا وتدوير العرض لتحديد عمليات التحويل اللازمة لـ SurfaceView أو TextureView
• تأكَّد من أنّ نسبة العرض إلى الارتفاع لـ Surface الناتج تتطابق مع نسبة العرض إلى الارتفاع لمعاينة الكاميرا لمنع حدوث تشويه

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

لمزيد من المعلومات، يُرجى الاطّلاع على دليل المطوّرين معاينة الكاميرا وفيديو تطبيق الكاميرا على عوامل شكل مختلفة.

الحلّ 4: تنفيذ إجراءات أساسية في الكاميرا باستخدام هدف 

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

لمزيد من المعلومات، يُرجى الاطّلاع على أهداف الكاميرا.

تجنُّب واجهة المستخدم الممدودة أو الأزرار التي لا يمكن الوصول إليها

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

تأكَّد من أنّ الأزرار وحقول النصوص والعناصر الأخرى ليست ممدودة على الشاشات الكبيرة.

ربما تكون قد ضبطت الأزرار وحقول النصوص والبطاقات على fillMaxWidth أو match_parent. يبدو هذا جيدًا على الهاتف. ومع ذلك، على جهاز لوحي أو جهاز قابل للطي في الوضع الأفقي، تمتد عناصر واجهة المستخدم على الشاشة الكبيرة بأكملها. في Jetpack Compose، يمكنك استخدام المعدِّل widthIn لضبط الحد الأقصى لعرض المكوّنات لتجنُّب المحتوى الممدود:

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

إذا فتح المستخدم تطبيقك في الوضع الأفقي على جهاز قابل للطي أو جهاز لوحي، قد يتم عرض أزرار الإجراءات، مثل حفظ أو تسجيل الدخول في أسفل الشاشة، خارج الشاشة. إذا لم يكن الحاوية قابلة للتمرير، قد يتم منع المستخدم من المتابعة. في Jetpack Compose، يمكنك إضافة المعدِّل verticalScroll إلى مكوّنك:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

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

يمكنك الاطّلاع على دليل إنشاء تنسيقات تكيّفية.

الاحتفاظ بالحالة عند تغيير الإعدادات

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

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

يمكنك الاطّلاع على دليل حفظ حالة واجهة المستخدم.

استهداف المستوى 37 لواجهة برمجة التطبيقات بحلول أغسطس 2027

إذا سبق لك إيقاف هذه التغييرات عند استهداف المستوى 36 لواجهة برمجة التطبيقات، لن يتأثر تطبيقك بإزالة خيار إيقاف التغييرات في Android 17 إلا بعد أن يستهدف تطبيقك المستوى 37 لواجهة برمجة التطبيقات. لمساعدتك في التخطيط مسبقًا وإجراء التعديلات اللازمة على تطبيقك، إليك الجدول الزمني الذي ستسري فيه هذه التغييرات:

• Android 17: ستكون التغييرات الموضّحة أعلاه هي التجربة الأساسية للأجهزة ذات الشاشات الكبيرة (أقل عرض للشاشة أكبر من 600 وحدة بكسل مستقلة الكثافة) للتطبيقات التي تستهدف المستوى 37 لواجهة برمجة التطبيقات. لن يتوفّر للمطوّرين خيار إيقاف التغييرات.

تختلف المواعيد النهائية لاستهداف مستوى معيّن لواجهة برمجة التطبيقات حسب متجر التطبيقات. بالنسبة إلى Google Play، يجب أن تستهدف التطبيقات الجديدة والتحديثات المستوى 37 لواجهة برمجة التطبيقات، ما يجعل هذا السلوك إلزاميًا للتوزيع في أغسطس 2027.

الاستعداد لنظام التشغيل Android 17

يُرجى الرجوع إلى صفحة تغييرات Android 17 للاطّلاع على جميع التغييرات التي تؤثر في التطبيقات في Android 17. لاختبار تطبيقك، نزِّل الإصدار التجريبي 1 من Android 17 وعدِّله إلى targetSdkPreview = “CinnamonBun” أو استخدِم اختبار توافق التطبيقات لتفعيل تغييرات معيّنة.

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

هذه فرصة لا تفوَّت. ابدأ الاستعداد لنظام التشغيل Android 17 اليوم.