التغييرات في السلوك: التطبيقات التي تستهدف الإصدار 17 من Android أو الإصدارات الأحدث

مثل الإصدارات السابقة، يتضمّن Android 17 تغييرات في السلوك قد تؤثر في تطبيقك. تنطبق التغييرات التالية في السلوك حصريًا على التطبيقات التي تستهدف Android 17 أو الإصدارات الأحدث. إذا كان تطبيقك يستهدف Android 17 أو إصدارًا أحدث، عليك تعديله ليتوافق مع هذه السلوكيات، حيثما ينطبق ذلك.

يُرجى أيضًا مراجعة قائمة التغييرات في السلوك التي تؤثر في جميع التطبيقات التي تعمل على Android 17 بغض النظر عن targetSdkVersion لتطبيقك.

تجربة المستخدم وواجهة مستخدم النظام

يتضمّن Android 17 التغييرات التالية التي تهدف إلى إنشاء تجربة مستخدم أكثر اتساقًا وسهولة.

التطبيق المصغّر لحدّ الذاكرة

بدءًا من الإصدار Android 17، يفرض النظام حدًا صارمًا على الذاكرة المستخدَمة في تحديثات RemoteViews للتطبيقات التي تستهدف الإصدار Android 17 (المستوى 37 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث. عندما يمرّر تطبيق عنصر RemoteViews إلى AppWidgetManager.updateAppWidget، تحسب system_server إجمالي استهلاك الذاكرة لجميع بيانات الصور في كل مجموعة اتجاه وحجم في الحمولة. إذا تجاوز إجمالي الذاكرة الحد الأقصى للنظام (mMaxWidgetBitmapMemory)، يرفض النظام التحديث ويعرض الخطأ IllegalArgumentException:

java.lang.IllegalArgumentException: RemoteViews for widget update exceeds maximum bitmap memory usage (used: XXXXX, max: YYYYY)

بالنسبة إلى التطبيقات التي تستهدف المستوى 36 أو أقل من واجهة برمجة التطبيقات، يسجّل النظام انتهاك الذاكرة هذا كتحذير (Slog.w) بدون طرح استثناء.

كيفية احتساب النظام للحدّ الأقصى للذاكرة

يضبط النظام ميزانية ذاكرة الصور النقطية للأداة على 6 * width * height بايت (1.5 * 4 * width * height، أي ما يعادل 1.5 ضعف حجم مخزن مؤقت ARGB_8888 بملء الشاشة) لإعدادات العرض النشطة. في المستوى 37 من واجهة برمجة التطبيقات والإصدارات الأحدث، تشمل عملية الاحتساب هذه ما يلي:

  • عناصر Bitmap في الذاكرة وعناصر Icon المستندة إلى الصور النقطية (Icon.TYPE_BITMAP وIcon.TYPE_ADAPTIVE_BITMAP) المخزَّنة في RemoteViews.mBitmapCache (مثل طلبات setImageViewBitmap أو Icon.createWithBitmap أو Icon.createWithAdaptiveBitmap أو Jetpack Glance ImageProvider(bitmap)). يتم احتساب كل مثيل فريد من Bitmap أو Icon المستند إلى الصور النقطية في mBitmapCache مرة واحدة لكل تسلسل هرمي في RemoteViews.
  • لا يتم احتساب الصور المستندة إلى معرّف الموارد المنتظم (URI) (Icon.createWithContentUri أو setImageViewUri أو Glance ImageProvider(uri)) ضمن الحد الأقصى لعدد وحدات بايت RemoteViews في الاتصال بين العمليات (IPC) في system_server، ولكن عملية مضيف التطبيق المصغّر تفك ترميز ملف content:// المُشار إليه بدقة كاملة في الذاكرة الديناميكية الخاصة به. يجب دائمًا كتابة صورة تم تقليل حجمها في context.cacheDir قبل عرضها من خلال معرّف موارد منتظم (URI) من النوع FileProvider.

خطوات الحدّ من التأثير

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

  1. احتساب ميزانية الذاكرة لوقت التشغيل من WindowMetrics: في مستوى واجهة برمجة التطبيقات 30 والإصدارات الأحدث، يمكنك قراءة حدود النافذة النشطة من WindowManager.currentWindowMetrics.bounds بدلاً من resources.displayMetrics. على الأجهزة المتعددة الدقة والأجهزة القابلة للطي، قد يعرض "displayMetrics" أبعاد الشاشة غير النشطة. قدِّر إجمالي ميزانية صور التطبيقات المصغّرة على النحو التالي: 6L * bounds.width() * bounds.height() كما هو موضّح في المثال التالي:

    private const val FALLBACK_MAX_BYTES = 15_000_000L

fun calculateWidgetMemoryCapBytes(context: Context): Long {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
        val wm = context.getSystemService(WindowManager::class.java)
            ?: return FALLBACK_MAX_BYTES
        val bounds = wm.currentWindowMetrics.bounds
        return 6L * bounds.width().toLong() * bounds.height().toLong()
    }
    val dm = context.resources.displayMetrics
    return 6L * dm.widthPixels.toLong() * dm.heightPixels.toLong()
}

  2. يجب تقليل دقة الصور لتتلاءم مع أبعاد العرض في التطبيق المصغّر واستخدام RGB_565: يجب فك ترميز الصور النقطية باستخدام قيم BitmapFactory.Options.inSampleSize من مضاعفات الرقم 2 بحجم يتناسب مع الحد الأقصى لأبعاد العرض في التطبيق المصغّر (maxWidthDp في maxHeightDp)، واستخدام Bitmap.Config.RGB_565 (2 بايت لكل بكسل) بدلاً من ARGB_8888 (4 بايت لكل بكسل) للصور الفوتوغرافية والصور المصغّرة غير الشفافة.

  3. رفع ترميز الصور النقطية خارج provideContent في Jetpack Glance: عند استخدام SizeMode.Responsive أو SizeMode.Exact، يستدعي Glance دالة lambda provideContent مرة واحدة لكل مجموعة حجم. يجب فك ترميز كل Bitmap مشترَك مرة واحدة داخل provideGlance قبل استدعاء provideContent لكي تشير جميع مجموعات الأحجام إلى مثيل Bitmap نفسه في RemoteViews.mBitmapCache.

  4. استخدام طلبات updateAppWidget الكاملة عند استبدال الصور: في عمليات التنفيذ الكلاسيكية لـ AppWidgetProvider، تجنَّب طلب AppWidgetManager.partiallyUpdateAppWidget لتبديل طرق عرض Bitmap أو Icon. تدمج التحديثات الجزئية الإجراءات الجديدة في شجرة RemoteViews الحالية في system_server بدون إزالة إجراءات الصور المخزّنة مؤقتًا سابقًا. يمكنك إنشاء تنسيق RemoteViews كامل واستدعاء updateAppWidget بدلاً من ذلك.

  5. توفير تنسيق احتياطي في حال حدوث خطأ: في Jetpack Glance، يمكنك إلغاء onCompositionError لعرض عنصر احتياطي RemoteViews بدون صور نقطية في حال تعذّر التحديث.

يمكنك فحص استخدام الذاكرة الحالي للصور النقطية المتسلسلة في التطبيق المصغّر على جهاز متصل من خلال تنفيذ ما يلي:

adb shell dumpsys appwidget

الوظيفة الأساسية

يتضمّن Android 17 التغييرات التالية التي تعدّل أو توسّع إمكانات أساسية متنوّعة في نظام Android.

تنفيذ جديد لـ MessageQueue بدون قفل

بدءًا من الإصدار 17 من نظام التشغيل Android، تحصل التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (المستوى 37 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث على تنفيذ جديد بدون قفل لـ android.os.MessageQueue. يؤدي التنفيذ الجديد إلى تحسين الأداء وتقليل اللقطات المفقودة، ولكنه قد يؤدي إلى تعطُّل البرامج التي تستخدم MessageQueue الحقول والأساليب الخاصة.

لمزيد من المعلومات، بما في ذلك استراتيجيات تخفيف الأثر، يُرجى الاطّلاع على إرشادات حول تغيير سلوك MessageQueue.

أصبحت الحقول النهائية الثابتة غير قابلة للتعديل الآن

لا يمكن للتطبيقات التي تعمل على الإصدار 17 من نظام التشغيل Android أو الإصدارات الأحدث والتي تستهدف الإصدار 17 من نظام التشغيل Android (المستوى 37 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث تغيير حقول static final. إذا حاول أحد التطبيقات تغيير حقل static final باستخدام الانعكاس، سيؤدي ذلك إلى حدوث IllegalAccessException. ستؤدي محاولة تعديل أحد هذه الحقول من خلال واجهات برمجة تطبيقات JNI (مثل SetStaticLongField()) إلى تعطُّل التطبيق.

تسهيل الاستخدام

يُجري Android 17 التغييرات التالية لتحسين ميزات تسهيل الاستخدام.

تسهيل استخدام لوحة المفاتيح الخارجية المعقّدة التي تستخدم أسلوب الإدخال (IME)

توفّر هذه الميزة واجهتَي برمجة التطبيقات الجديدتَين AccessibilityEvent وTextAttribute لتحسين الوصف الشفهي للشاشة الذي يقدّمه قارئ الشاشة عند إدخال النصوص بلغات CJKV. يمكن الآن لتطبيقات أساليب الإدخال (IME) للغات الصينية واليابانية والكورية والفيتنامية (CJKV) الإشارة إلى ما إذا تم اختيار مرشّح لتحويل النص أثناء إنشاء النص. يمكن للتطبيقات التي تحتوي على حقول تعديل تحديد أنواع تغيير النص عند إرسال أحداث تسهيل الاستخدام التي تم تغيير النص فيها. على سبيل المثال، يمكن للتطبيقات تحديد أنّ تغييرًا في النص حدث أثناء إنشاء النص، أو أنّ تغييرًا في النص نتج عن عملية تثبيت. يؤدي ذلك إلى تفعيل خدمات تسهيل الاستخدام، مثل برامج قراءة الشاشة، لتقديم ملاحظات أكثر دقة استنادًا إلى طبيعة تعديل النص.

عدد التطبيقات التي تستخدم حِزم SDK

  • تطبيقات أسلوب الإدخال (IME): عند ضبط نص الإنشاء في حقول التعديل، يمكن لتطبيقات أسلوب الإدخال استخدام TextAttribute.Builder.setTextSuggestionSelected() للإشارة إلى ما إذا تم اختيار مرشّح معيّن للإحالة الناجحة.

  • التطبيقات التي تتضمّن حقول تعديل: يمكن للتطبيقات التي تحتفظ بـ InputConnection مخصّص استرداد بيانات اختيار المرشّحين من خلال طلب TextAttribute.isTextSuggestionSelected(). يجب أن تستدعي هذه التطبيقات AccessibilityEvent.setTextChangeTypes() عند إرسال أحداث TYPE_VIEW_TEXT_CHANGED. ستكون هذه الميزة مفعَّلة تلقائيًا في التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (المستوى 37 من واجهة برمجة التطبيقات) وتستخدم معيار TextView. (أي أنّ TextView سيتولّى استرداد البيانات من محرِّر أسلوب الإدخال وضبط أنواع تغيير النص عند إرسال الأحداث إلى خدمات تسهيل الاستخدام).

  • خدمات تسهيل الاستخدام: يمكن لخدمات تسهيل الاستخدام التي تعالج أحداث TYPE_VIEW_TEXT_CHANGED استدعاء AccessibilityEvent.getTextChangeTypes() لتحديد طبيعة التعديل وضبط استراتيجيات الملاحظات وفقًا لذلك.

الخصوصية

يتضمّن Android 17 التغييرات التالية لتحسين خصوصية المستخدم.

تم تفعيل بروتوكول ECH (Encrypted Client Hello)

يقدّم Android 17 دعمًا على مستوى النظام الأساسي لبروتوكول Encrypted Client Hello ‏(ECH)، وهو إضافة لبروتوكول أمان طبقة النقل (TLS) تعزّز خصوصية المستخدم من خلال تشفير إشارة اسم الخادم (SNI) في تأكيد اتصال بروتوكول أمان طبقة النقل (TLS). يساعد هذا التشفير في منع مراقبي الشبكة من التعرّف بسهولة على النطاق المحدّد الذي يتصل به تطبيقك.

بالنسبة إلى التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 37) أو الإصدارات الأحدث، يتم استخدام ECH لاتصالات بروتوكول أمان طبقة النقل (TLS). لا يتم تفعيل ECH إلا إذا كانت مكتبة الشبكات التي يستخدمها التطبيق (مثل HttpEngine أو WebView أو OkHttp) تتضمّن ميزة ECH وكان الخادم البعيد متوافقًا أيضًا مع بروتوكول ECH. إذا تعذّر التفاوض بشأن ECH، يرسل العميل إضافة ECH بمحتوى عشوائي (آلية تُعرف باسم ECH GREASE). يمكنك الاطّلاع على RFC 9849 لمزيد من التفاصيل حول آلية عمل ECH GREASE.

للسماح للتطبيقات بتخصيص هذا السلوك، يضيف Android 17 عنصر <domainEncryption> جديدًا إلى ملف "إعدادات أمان الشبكة". يمكن للمطوّرين استخدام <domainEncryption> ضمن علامات <base-config> أو <domain-config> لاختيار وضع ECH (على سبيل المثال، "enabled" أو "disabled") على مستوى عام أو على مستوى النطاق.

لمزيد من المعلومات، يُرجى الاطّلاع على مستندات Encrypted Client Hello.

إذن الوصول إلى الشبكة المحلية مطلوب للتطبيقات التي تستهدف الإصدار 17 من Android

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

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

لمزيد من المعلومات، يُرجى الاطّلاع على مستندات إذن الشبكة المحلية.

إخفاء كلمات المرور من الأجهزة الفعلية

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

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

إذا كان المستخدم يستخدم شاشة الجهاز التي تعمل باللمس، يطبّق النظام الإعداد الجديد show_passwords_touch.

حماية كلمات المرور الصالحة لمرة واحدة (OTP) في رسائل SMS العادية

بدءًا من الإصدار 17 من نظام التشغيل Android، سيتم توسيع نطاق حماية كلمات المرور الصالحة لمرة واحدة (OTP) في الرسائل القصيرة لتشمل الرسائل القصيرة العادية (الرسائل القصيرة التي تحتوي على كلمة مرور صالحة لمرة واحدة ولا تستخدم تنسيقات WebOTP أو SMS Retriever). بالنسبة إلى معظم التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 37) أو الإصدارات الأحدث، لا تصبح رسائل SMS هذه متاحة إلا بعد مرور ثلاث ساعات على استلامها. يهدف هذا التأخير إلى المساعدة في منع الاستيلاء على كلمة المرور الصالحة لمرة واحدة. خلال فترة التأخير التي تبلغ ثلاث ساعات، يتم حجب بث SMS_RECEIVED_ACTION وتتم فلترة طلبات البحث في قاعدة بيانات مقدّم خدمة الرسائل القصيرة. وتكون الرسالة القصيرة SMS متاحة لهذه التطبيقات بعد التأخير.

يُستثنى من هذا التأخير بعض التطبيقات، مثل تطبيق المساعد التلقائي للرسائل القصيرة والتطبيقات المصاحبة للأجهزة المتصلة وما إلى ذلك. يجب أن تنتقل جميع التطبيقات التي تعتمد على قراءة رسائل SMS لاستخراج كلمات المرور الصالحة لمرة واحدة إلى استخدام واجهات برمجة التطبيقات SMS Retriever أو SMS User Consent لضمان استمرار عملها.

الأمان

يقدّم Android 17 التحسينات التالية على أمان الأجهزة والتطبيقات.

أمان النشاط

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

تشمل التأثيرات الرئيسية على المطوّرين ما يلي:

  • تعزيز ميزة "بدء النشاط في الخلفية" (BAL) وتحسين عملية الموافقة: نعمل على تحسين القيود المفروضة على ميزة "بدء النشاط في الخلفية" (BAL) من خلال توسيع نطاق الحماية ليشمل IntentSender. وعلى المطوّرين نقل البيانات من الثابت القديم MODE_BACKGROUND_ACTIVITY_START_ALLOWED. بدلاً من ذلك، يجب استخدام عناصر تحكّم دقيقة مثل MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE، التي تقيّد بدء الأنشطة في السيناريوهات التي يكون فيها تطبيق الاتصال مرئيًا، ما يقلّل بشكل كبير من فرص الهجوم.
  • أدوات الاعتماد: على المطوّرين استخدام وضع التدقيق الصارم وعمليات التحقّق المحدَّثة من الأخطاء البرمجية لتحديد الأنماط القديمة وضمان الاستعداد لمتطلبات حزمة تطوير البرامج (SDK) المستهدَفة في المستقبل.

تفعيل شفافية الشهادة تلقائيًا

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

Safer Native DCL—C

إذا كان تطبيقك يستهدف الإصدار 17 من نظام التشغيل Android (المستوى 37 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث، فإنّ ميزة "الحماية الأكثر أمانًا لتحميل الرموز البرمجية الديناميكية" التي تم تقديمها في الإصدار 14 من نظام التشغيل Android لملفات DEX وJAR تمتد الآن لتشمل المكتبات المجمّعة من رموز برمجية أصلية.

يجب وضع علامة "للقراءة فقط" على جميع الملفات الأصلية التي يتم تحميلها باستخدام System.load(). وإلا، سيعرض النظام UnsatisfiedLinkError.

ننصح بأن تتجنّب التطبيقات تحميل الرموز البرمجية ديناميكيًا كلما أمكن ذلك، لأنّ ذلك يزيد بشكل كبير من خطر اختراق التطبيق من خلال حقن الرموز البرمجية أو التلاعب بها.

تقييد حقول معلومات تحديد الهوية الشخصية في عرض بيانات CP2

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

يمكن للتطبيقات التي تستخدم هذه الأعمدة من ContactsContract.Data استخراجها من ContactsContract.RawContacts بدلاً من ذلك، من خلال الانضمام إلى RAW_CONTACT_ID.

فرض عمليات تحقّق صارمة من SQL في CP2

بالنسبة إلى التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 37) والإصدارات الأحدث، يفرض مقدِّم جهات الاتصال 2 (CP2) عملية تحقّق صارمة من طلبات البحث في SQL عند الوصول إلى جدول ContactsContract.Data بدون إذن READ_CONTACTS.

من خلال هذا التغيير، إذا لم يكن لدى التطبيق إذن READ_CONTACTS، يتم ضبط خيارَي StrictColumns وStrictGrammar عند طلب البحث في جدول ContactsContract.Data. إذا كان طلب البحث يستخدم نمطًا غير متوافق مع هذه الأنماط، سيتم رفضه وسيؤدي إلى ظهور استثناء.

Intelligence

يتضمّن Android 17 التغييرات التالية على ذكاء النظام.

إيقاف setContentCaptureEnabled نهائيًا

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

اعتبارًا من الإصدار 17 من نظام التشغيل Android، سيتم إيقاف طريقة واجهة برمجة التطبيقات ContentCaptureManager.setContentCaptureEnabled(boolean) نهائيًا. بالنسبة إلى التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 37) أو الإصدارات الأحدث، لن يؤدي استدعاء setContentCaptureEnabled(false) إلى إيقاف ميزة "التقاط المحتوى".

إذا كان تطبيقك بحاجة إلى مواصلة إيقاف ميزة "التقاط المحتوى" أو حظر التقاط محتوى الشاشة من قِبل النظام، عليك الانتقال إلى استخدام مَعلمة تنسيق النافذة FLAG_SECURE.

لإيقاف ميزة "التقاط المحتوى"، اضبط العلامة FLAG_SECURE على نافذتك كما هو موضّح في المثال التالي:

Kotlin

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

Java

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

لمزيد من التفاصيل، يُرجى الاطّلاع على المستندات المرجعية حول WindowManager.LayoutParams.FLAG_SECURE.

الوسائط

يتضمّن Android 17 التغييرات التالية في سلوك الوسائط.

تعزيز أمان الصوت في الخلفية

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

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

  • يجب أن تتوفّر في الخدمة التي تعمل في المقدّمة إمكانات "أثناء الاستخدام" (WIU).
  • يجب أن يحصل التطبيق على إذن المنبّه الدقيق وأن يتفاعل مع البث الصوتي USAGE_ALARM.

لمزيد من المعلومات، بما في ذلك استراتيجيات التخفيف من آثار هذه المشكلة، يُرجى الاطّلاع على تعزيز أمان الصوت في الخلفية.

أشكال الأجهزة

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

تغييرات في واجهة برمجة التطبيقات الخاصة بالمنصة لتجاهل قيود اتجاه الشاشة وإمكانية تغيير الحجم ونسبة العرض إلى الارتفاع على الشاشات الكبيرة (أصغر عرض يساوي 600 وحدة بكسل مستقلة الكثافة أو أكثر)

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

لمزيد من المعلومات، يُرجى الاطّلاع على يتم تجاهل القيود المفروضة على الاتجاه وإمكانية تغيير الحجم.

إمكانية الاتصال

يقدّم Android 17 التغيير التالي لتحسين الاتساق والتوافق مع سلوك Java InputStream العادي لمقابس بلوتوث من نوع RFCOMM.

سلوك ثابت للدالة read()‎ الخاصة بـ BluetoothSocket في RFCOMM

بالنسبة إلى التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (المستوى 37 لواجهة برمجة التطبيقات)، فإنّ طريقة read() الخاصة بـ InputStream الناتج من BluetoothSocket المستند إلى RFCOMM ستُرجع الآن القيمة -1 عند إغلاق المقبس أو انقطاع الاتصال.

يجعل هذا التغيير سلوك مقبس RFCOMM متوافقًا مع مقابس LE CoC ويتوافق مع مستندات InputStream.read() القياسية التي تنص على أنّه يتم عرض -1 عند الوصول إلى نهاية البث.

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