أخبار المنتجات

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

قراءة لمدة 6 دقائق
Miguel Montemayor
مهندسة علاقات المطوّرين

مع إصدار 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

سمات البيان/واجهة برمجة التطبيقاتالقيم التي تم تجاهلها
screenOrientationportrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape
setRequestedOrientation()‎portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape
resizeableActivityالكل
minAspectRatioالكل
maxAspectRatioالكل

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

إعداد تطبيقك

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

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

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

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

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

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

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

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

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

camera_preview_issue.png

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

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

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

الحلّ 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 بدلاً من الدمج مع مكتبة كاميرا، وذلك لتسهيل الصيانة والقدرة على التكيّف. 

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

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

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

elementsLS.png

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

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

تأليف:

متابعة القراءة