مع إطلاق 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.
| سمات ملف البيان/واجهة برمجة التطبيقات | القيم التي يتم تجاهلها |
| screenOrientation | portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape |
| setRequestedOrientation() | portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape |
| resizeableActivity | الكل |
| minAspectRatio | الكل |
| maxAspectRatio | الكل |
بالإضافة إلى ذلك، يحتفظ المستخدمون بالتحكّم. في إعدادات نسبة العرض إلى الارتفاع، يمكن للمستخدمين الموافقة صراحةً على استخدام السلوك المطلوب للتطبيق.
إعداد تطبيقك
ستحتاج التطبيقات إلى إتاحة تنسيقات العرض الأفقي والعمودي لأحجام العرض في النطاق الكامل لنسب العرض إلى الارتفاع التي يمكن للمستخدمين اختيار استخدام التطبيقات فيها، بما في ذلك النوافذ التي يمكن تغيير حجمها، لأنّه لن تكون هناك طريقة لتقييد نسبة العرض إلى الارتفاع والاتجاه إلى الوضع العمودي أو الأفقي.
اختبار تطبيقك
خطوتك الأولى هي اختبار تطبيقك مع هذه التغييرات للتأكّد من أنّه يعمل بشكل جيد على جميع أحجام الشاشات.
استخدِم الإصدار التجريبي Android 17 Beta 1 مع محاكيات 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 اليوم.
-
أخبار المنتجاتخلال فعالية Galaxy Unpacked اليوم، كشفت Samsung عن أحدث تشكيلة من الأجهزة القابلة للطي والأجهزة القابلة للارتداء. بالنسبة إلى المطوّرين، يعني ذلك أنّ مجموعة أشكال الأجهزة وأحجام الشاشات وأوضاع الأجهزة التي يحتاج تطبيقك إلى دعمها تتوسّع مرة أخرى.
Fahd Imtiaz, Miguel Montemayor • مدّة القراءة: 3 دقائق -
أخبار المنتجاتمع انضمام أشكال أجهزة جديدة إلى منظومة Android المتكاملة، مثل Pixel 10 Pro Fold، أصبح تطوير التطبيقات التكيُّفية أمرًا ضروريًا لإنشاء تجارب مستخدم عالية الجودة على الهواتف والأجهزة اللوحية والأجهزة القابلة للطي.
Fahd Imtiaz, Miguel Montemayor • مدّة القراءة: 3 دقائق -
أخبار المنتجاتبما أنّ Unity تشغّل أكثر من نصف جميع الألعاب على الأجهزة الجوّالة في جميع أنحاء العالم، فإنّ الانطباعات الأولى مهمة. بالنسبة إلى مطوّري الألعاب، تُعدّ تجربة الإعداد السلسة والموثوقة للاعبين ضرورية لتعزيز معدّل الاحتفاظ باللاعبين من اليوم الأول وزيادة تفاعلهم على المدى الطويل.
Michelle Martin • مدّة القراءة: دقيقة واحدة
يمكنك الحصول على آخر الإحصاءات حول تطوير تطبيقات Android في بريدك الوارد أسبوعيًا.