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

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

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

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

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

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

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

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

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

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

إعداد تطبيقك

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

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

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

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

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

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

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

التأكّد من توافق الكاميرا

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

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

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

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

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

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

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

لمزيد من المعلومات، راجِع تنفيذ معاينة في مستندات CameraX.

الحلّ 2: CameraViewfinder 

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

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

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

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

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

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

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

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

إذا لم تكن بحاجة إلى العديد من ميزات الكاميرا، يمكنك استخدام حل بسيط ومباشر لتنفيذ إجراءات أساسية، مثل التقاط صورة أو فيديو باستخدام تطبيق الكاميرا التلقائي على الجهاز. في هذه الحالة، يمكنك ببساطة استخدام 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 اليوم.