تغييرات السلوك: جميع التطبيقات

يتضمّن نظام Android 10 تغييرات في السلوك قد تؤثر في تطبيقك. تُطبَّق التغييرات الواردة في هذه الصفحة على تطبيقك عند تشغيله. في Android 10، بغض النظر عن targetSdkVersion في التطبيق. يجب عليك اختبار تطبيقك وتعديله حسب الحاجة لإحداث هذه التغييرات بشكل صحيح.

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

ملاحظة: بالإضافة إلى التغييرات المذكورة في هذه الصفحة، إنّ نظام Android 10 إلى إنشاء عدد كبير من التغييرات والقيود المستندة إلى الخصوصية، بما في ذلك ما يلي:

  • الوصول إلى الموقع الجغرافي للجهاز في الخلفية
  • بدء النشاط في الخلفية
  • معلومات الجمهور ذي الاهتمامات المشتركة في جهات الاتصال
  • التوزيع العشوائي لعناوين MAC
  • البيانات الوصفية للكاميرا
  • نموذج الأذونات

تؤثر هذه التغييرات في جميع التطبيقات وتُحسِّن خصوصية المستخدم. لمزيد من المعلومات حول كيفية التوافق مع هذه التغييرات، يُرجى الاطّلاع على صفحة تغييرات الخصوصية.

قيود الواجهة غير المتوفرة في حزمة SDK

للمساعدة في ضمان ثبات التطبيق وتوافُقه، بدأت المنصة في فرض قيود على والواجهات غير المستندة إلى حزمة SDK يمكن لتطبيقك استخدامها في Android 9 (المستوى 28 من واجهة برمجة التطبيقات). يتضمّن Android 10 قوائم معدّلة من الواجهات المقيّدة غير المستندة إلى حزمة تطوير البرامج (SDK) بناءً على التعاون مع مطوّري تطبيقات Android وأحدث اختبار داخلي. هدفنا هو التأكد من أن الجمهور أن تتوفّر بدائل قبل أن نحظر الواجهات التي لا تتوفّر لها حزمة تطوير البرامج (SDK).

إذا لم تكن تستهدف Android 10 (المستوى 29 من واجهة برمجة التطبيقات)، ستتغيّر بعض هذه التغييرات على الفور. ومع ذلك، على الرغم من أنّه يمكنك حاليًا استخدام بعض الواجهات غير المستندة إلى حزمة تطوير البرامج (SDK) (بناءً على مستوى واجهة برمجة التطبيقات المستهدَف في تطبيقك) ينطوي استخدام أي حقل أو طريقة غير متوفرة في حزمة SDK دائمًا على مخاطرة كبيرة بإتلاف التطبيق.

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

لمزيد من المعلومات، يُرجى الاطّلاع على مقالة تعديلات على القيود المفروضة على الواجهة غير المتوفرة في حزمة تطوير البرامج (SDK) في الإصدار Android 10. راجِع المقالة القيود المفروضة على الواجهات غير المستندة إلى حزمة تطوير البرامج (SDK).

التنقُّل بالإيماءات

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

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

كرونة دنماركية

يتضمّن Android 10 التغييرات التالية على NDK.

لا يمكن أن تحتوي العناصر المشتركة على عمليات نقل النص.

حظر الإصدار 6.0 من نظام التشغيل Android (المستوى 23 من واجهة برمجة التطبيقات) استخدام عمليات إعادة تحديد موضع النص في العناصر المشترَكة. يجب تحميل الرمز كما هو، ويجب عدم تعديله. يعمل هذا التغيير على تحسين الأمان وأوقات تحميل التطبيقات.

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

التغييرات في مكتبات Bionic ومسارات الربط الديناميكية

بدءًا من نظام التشغيل Android 10، تُعد المسارات العديدة روابط رمزية بدلاً من ملفات عادية. التطبيقات التي اعتمدت على المسارات باعتبارها ملفات عادية قد يعطل:

  • /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
  • /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
  • /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
  • /system/bin/linker -> /apex/com.android.runtime/bin/linker

وتنطبق هذه التغييرات أيضًا على صيغ 64 بت للملف، مع تم استبدال lib/ بـ lib64/.

للتوافق، يتم توفير الروابط الرمزية في المسارات القديمة. على سبيل المثال: /system/lib/libc.so هو رابط رمزي /apex/com.android.runtime/lib/bionic/libc.so إذًا، سيستمر تطبيق "dlopen(“/system/lib/libc.so”)" في العمل، ولكن ستتمكّن التطبيقات من العثور على الفرق عند محاولتهم فحص المكتبات المحملة بالفعل من خلال قراءة /proc/self/maps أو ما شابه ذلك، وهو أمر غير معتاد، ولكننا اكتشفنا فإن بعض التطبيقات تفعل ذلك كجزء من عملية مكافحة الاختراق. إذا كان الأمر كذلك، فإن يجب إضافة مسارات /apex/… كمسارات صالحة لملفات Bionic.

مكتبات أو برامج ثنائية للنظام تم تعيينها إلى ذاكرة التنفيذ فقط

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

ويمكنك تحديد ما إذا كان هذا السلوك قد تسبب في حدوث عطل عن طريق فحص ملف ملف Tombstone في /data/tombstones/. تعطُّل متعلق بالتنفيذ فقط يحتوي على رسالة الإلغاء التالية:

Cause: execute-only (no-read) memory access error; likely due to data in .text.

وللتغلب على هذه المشكلة لإجراء عمليات مثل فحص الذاكرة، من من الممكن وضع علامة على أجزاء التنفيذ فقط كـ read+تنفيذ من خلال استدعاء mprotect() ومع ذلك، نوصي بشدة بإعادة ضبط الإعدادات على بالتنفيذ فقط بعد ذلك، حيث يوفر إعداد إذن الوصول هذا حماية تطبيقك ومستخدمي تطبيقك

الأمان

يتضمن Android 10 تغييرات الأمان التالية.

تم تفعيل الإصدار 1.3 من بروتوكول أمان طبقة النقل (TLS) تلقائيًا

في نظام التشغيل Android 10 والإصدارات الأحدث، يتم تفعيل طبقة النقل الآمنة (TLS) الإصدار 1.3 تلقائيًا لجميع اتصالات بروتوكول أمان طبقة النقل (TLS). في ما يلي بعض التفاصيل المهمة عن الإصدار 1.3 من بروتوكول أمان طبقة النقل (TLS). التنفيذ:

  • لا يمكن تخصيص مجموعات تشفير TLS 1.3. تشفير TLS 1.3 المتوافق مُفعَّلة دائمًا عند تفعيل TLS 1.3. أي محاولة لإيقاف من خلال استدعاء setEnabledCipherSuites() تجاهله.
  • عند التفاوض على بروتوكول أمان طبقة النقل 1.3، يتمّ استدعاء HandshakeCompletedListener العناصر قبل إضافة الجلسات إلى ذاكرة التخزين المؤقت للجلسات. (في الإصدار 1.2 من بروتوكول أمان طبقة النقل (TLS) والنُسخ السابقة الأخرى، يُطلق على هذه الكائنات اسم بعد إضافة الجلسات. إلى ذاكرة التخزين المؤقت للجلسة).
  • في بعض الحالات التي تطرح فيها مثيلات SSLEngine تفعيل SSLHandshakeException في الإصدارات السابقة من Android، تعرض هذه المثيلات SSLProtocolException بدلاً من ذلك على نظام التشغيل Android 10 والإصدارات الأحدث.
  • لا يتوفّر وضع "المراسلة النصية في الوقت الفعلي" (RTT).

ويمكنك، إن أردت، الحصول على SSLContext تم إيقاف الإصدار 1.3 من بروتوكول أمان طبقة النقل (TLS) فيه عن طريق الاتصال SSLContext.getInstance("TLSv1.2") يمكنك أيضًا تمكين أو تعطيل إصدارات البروتوكول على أساس كل اتصال من خلال جارٍ الاتصال بالرقم setEnabledProtocols() على كائن مناسب.

الشهادات الموقَّعة باستخدام خوارزمية SHA-1 غير موثوق بها في بروتوكول أمان طبقة النقل (TLS)

في نظام التشغيل Android 10، الشهادات التي تستخدم خوارزمية التجزئة SHA-1 لا يتم الوثوق بهم في اتصالات بروتوكول أمان طبقة النقل. لم تصدر مراجع التصديق الجذر هذه الشهادة منذ عام 2016، ولم تعُد موثوقًا بها في Chrome أو المتصفحات الرئيسية الأخرى

تخفق أي محاولة للاتصال إذا كان الاتصال بموقع ويب يقدم باستخدام خوارزمية SHA-1.

التغييرات والتحسينات في سلوك KeyChain

تسمح بعض المتصفّحات، مثل Google Chrome، للمستخدمين باختيار شهادة عندما يُرسِل خادم بروتوكول أمان طبقة النقل رسالة طلب شهادة كجزء من عملية تأكيد اتصال بروتوكول أمان طبقة النقل. اعتبارًا من Android 10، تراعي عناصر KeyChain جهات الإصدار المواصفات الرئيسية لمواصفات المفاتيح عند استدعاء KeyChain.choosePrivateKeyAlias() عرض طلب باختيار شهادة للمستخدمين على وجه الخصوص، لا تحتوي على خيارات لا تلتزم بمواصفات الخادم.

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

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

تغييرات أخرى في بروتوكول أمان طبقة النقل (TLS) والتشفير

كان هناك العديد من التغييرات الطفيفة في مكتبات بروتوكول أمان طبقة النقل والتشفير سارية على Android 10:

  • إظهار التشفير AES/GCM/NoPadding وCha20/Poly1305/NoPadding أكبر أحجام دقيقة للمخزن المؤقت من getOutputSize()
  • يتم حذف مجموعة رموز TLS_FALLBACK_SCSV من محاولات الاتصال باستخدام ببروتوكول الحد الأقصى من بروتوكول أمان طبقة النقل (TLS) الإصدار 1.2 أو أعلى. بسبب التحسينات في خادم بروتوكول أمان طبقة النقل (TLS) كإجراء احتياطي خارجي لبروتوكول أمان طبقة النقل (TLS) بدلاً من ذلك، ننصح بالاعتماد على عملية التفاوض على إصدار بروتوكول أمان طبقة النقل (TLS).
  • ChaCha20-Poly1305 هو اسم بديل لـ ChaCha20/Poly1305/NoPadding.
  • لا تُعتبر أسماء المضيف التي تتضمّن نقاطًا لاحقة أسماء مضيفين صالحة لإشارة اسم الخادم (SNI).
  • الإضافة المتوافقة_signature_algorithms في CertificateRequest هي يجب الالتزام بها عند اختيار مفتاح توقيع للردود على الشهادة.
  • يمكن استخدام مفاتيح التوقيع المعتمة، مثل تلك المتوفرة من Android Keystore، مع توقيعات RSA-PSS في بروتوكول أمان طبقة النقل (TLS)

عمليات بث Wi-Fi Direct

على نظام التشغيل Android 10، تتعلّق عمليات البث التالية بشبكة Wi-Fi الزيارات المباشرة غير ثابتة:

إذا اعتمد تطبيقك على تلقّي عمليات البث هذه عند التسجيل للأسباب التالية: كان ثابتًا، لذا استخدِم طريقة get() المناسبة عند الإعداد والحصول على المعلومات بدلاً من ذلك.

إمكانات Wi-Fi Aware

يضيف نظام التشغيل Android 10 إمكانية إنشاء مآخذ TCP/UDP بسهولة باستخدام مسارات بيانات Wi-Fi Aware . لإنشاء مقبس TCP/UDP للاتصال بـ ServerSocket، يجب على العميل يحتاج الجهاز إلى معرفة عنوان IPv6 ومنفذ الخادم. في السابق، كان يجب إرسال هذه المعلومات خارج النطاق، مثلاً باستخدام رسائل الربط بين الأجهزة عبر البلوتوث أو Wi-Fi Aware في المستوى 2، أو اكتشافها ضمن النطاق باستخدام بروتوكولات أخرى، مثل mDNS. مع في نظام التشغيل Android 10، يمكن نقل المعلومات كجزء من عملية إعداد الشبكة.

يمكن للخادم تنفيذ أي من الإجراءَين التاليَين:

  • عليك إعداد "ServerSocket" ثم ضبط المنفذ أو الحصول عليه لاستخدامه.
  • حدِّد معلومات المنفذ كجزء من طلب الشبكة لخدمة Wi-Fi Aware.

يوضح نموذج الرمز البرمجي التالي كيفية تحديد معلومات المنفذ كجزء من برنامج طلب الشبكة:

Kotlin

val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
  .setPskPassphrase("some-password")
  .setPort(ss.localPort)
  .build()

val myNetworkRequest = NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build()

Java

ServerSocket ss = new ServerSocket();
WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
  .Builder(discoverySession, peerHandle)
  .setPskPassphrase(“some-password”)
  .setPort(ss.getLocalPort())
  .build();

NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build();

بعد ذلك، يُجري العميل طلب شبكة Wi-Fi Aware للحصول على عنوان IPv6 و المنفذ اللذين يقدّمهما الخادم:

Kotlin

val callback = object : ConnectivityManager.NetworkCallback() {
  override fun onAvailable(network: Network) {
    ...
  }
  
  override fun onLinkPropertiesChanged(network: Network,
      linkProperties: LinkProperties) {
    ...
  }

  override fun onCapabilitiesChanged(network: Network,
      networkCapabilities: NetworkCapabilities) {
    ...
    val ti = networkCapabilities.transportInfo
    if (ti is WifiAwareNetworkInfo) {
       val peerAddress = ti.peerIpv6Addr
       val peerPort = ti.port
    }
  }
  override fun onLost(network: Network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback)

Java

callback = new ConnectivityManager.NetworkCallback() {
  @Override
  public void onAvailable(Network network) {
    ...
  }
  @Override
  public void onLinkPropertiesChanged(Network network,
      LinkProperties linkProperties) {
    ...
  }
  @Override
  public void onCapabilitiesChanged(Network network,
      NetworkCapabilities networkCapabilities) {
    ...
    TransportInfo ti = networkCapabilities.getTransportInfo();
    if (ti instanceof WifiAwareNetworkInfo) {
       WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
       Inet6Address peerAddress = info.getPeerIpv6Addr();
       int peerPort = info.getPort();
    }
  }
  @Override
  public void onLost(Network network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback);

SYSTEM_ALERT_WINDOW على أجهزة Go

لا يمكن للتطبيقات التي تعمل على أجهزة Android 10 (إصدار Go) تلقّي SYSTEM_ALERT_WINDOW إذن. وذلك لأن رسم نوافذ التراكب يستخدم ذاكرة زائدة، ما يؤثر سلبًا في أداء أجهزة Android منخفضة الذاكرة الأجهزة.

إذا تلقّى تطبيق يعمل على جهاز يعمل بالإصدار Go من نظام التشغيل Android 9 أو إصدار أقدم إذن SYSTEM_ALERT_WINDOW، يحتفظ التطبيق بالإذن حتى إذا تمت ترقية الجهاز إلى الإصدار 10 من نظام التشغيل Android. ومع ذلك، فإن التطبيقات التي لا تحتوي على هذه الميزة لا يمكن منح الإذن بعد ترقية الجهاز.

إذا أرسل أحد التطبيقات على جهاز Go هدفًا مع الإجراء ACTION_MANAGE_OVERLAY_PERMISSION، يرفض النظام الطلب تلقائيًا، وينقل المستخدم إلى شاشة الإعدادات التي توضح أن الإذن غير مسموح به لأنه يؤدي إلى إبطاء الجهاز. إذا استدعى تطبيق على جهاز Go دالة Settings.canDrawOverlays()، ستعرض الطريقة دائمًا القيمة false. مرة أخرى، لا تنطبق هذه القيود على التطبيقات. الذي حصل على إذن SYSTEM_ALERT_WINDOW قبل ضبط الجهاز إلى Android 10.

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

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

بفضل واجهة برمجة التطبيقات المستهدَفة على Google Play والمتطلبات، لا تظهر هذه التحذيرات للمستخدم إلا عند تشغيل تطبيق لم يتم تحديثه. مؤخرًا. بالنسبة إلى التطبيقات التي يتم توزيعها من خلال متاجر أخرى، يجب استخدام واجهة برمجة تطبيقات مستهدَفة مشابهة متطلبات السياسة خلال عام 2019. لمزيد من المعلومات عن هذه ، راجِع توسيع متطلبات مستوى واجهة برمجة التطبيقات المستهدَف في 2019

تمت إزالة مجموعات رموز SHA-2 CBC

لقد أزلنا مجموعات رموز SHA-2 CBC التالية من النظام الأساسي:

  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

تعتبر مجموعات الرموز هذه أقل أمانًا من مجموعات التشفير المشابهة التي تستخدم GCM، وتدعم معظم الخوادم كلاً من متغيري GCM وCBC لهذه التشفير الأجنحة أو عدم دعم أي منها.

استخدام التطبيق

يقدّم نظام التشغيل Android 10 التغييرات التالية في السلوك المتعلّقة باستخدام التطبيقات:

  • تحسينات استخدام تطبيق UsageStats - يتتبّع نظام Android 10 استخدام التطبيق بدقة من خلال إحصاءات الاستخدام عندما تكون التطبيقات في وضع "تقسيم الشاشة" أو "نافذة ضمن النافذة" بالإضافة إلى ذلك، يتتبّع الإصدار Android 10 استخدام التطبيقات الفورية بشكل صحيح.

  • تدرّج الرمادي لكل تطبيق - يمكن لنظام Android 10 ضبط وضع العرض بتدرج الرمادي لكل تطبيق على حدة.

  • حالة تشتيت الانتباه لكل تطبيق - يمكن لنظام Android 10 ضبط التطبيقات بشكل انتقائي على "حالة تشتيت الانتباه". أين يتم حجب إشعاراتهم ولا تظهر كتطبيقات مقترحة.

  • التعليق والتشغيل - في نظام Android 10، لا يمكن للتطبيقات المعلّقة تشغيل الصوت.

التغييرات في اتصال HTTPS

إذا أرسل تطبيق يعمل بنظام التشغيل Android 10 null إلى setSSLSocketFactory()، يحدث IllegalArgumentException . في النُسخ السابقة، يتم تمرير null إلى setSSLSocketFactory() كان له التأثير نفسه مثل تمرير القيمة الافتراضية الحالية المصنع.

تم إيقاف مكتبة android.preference نهائيًا.

تم إيقاف مكتبة android.preference نهائيًا اعتبارًا من الإصدار 10 من نظام التشغيل Android. وبدلاً من ذلك، على مطوّري البرامج استخدام مكتبة الإعدادات المفضَّلة AndroidX التي تشكّل جزءًا من Android Jetpack. للحصول على موارد إضافية للمساعدة في الهجرة التطوير، يمكنك الاطلاع على الإصدار المحدث من إعدادات الدليل مع العينة العلنية التطبيق والمستندات المرجعية

التغييرات في مكتبة الأداة الخاصة بملف ZIP

يقدِّم Android 10 التغييرات التالية على الفئات في java.util.zip. حزمة معالجة ملفات ZIP. هذه التغييرات تجعل سلوك المكتبة أكثر متسقة بين Android والأنظمة الأساسية الأخرى التي تستخدم java.util.zip

آلة نفخ

في النُسخ السابقة، طرحت بعض الطرق في فئة Inflater السمة IllegalStateException إذا كان تم استدعاء بعد اتصال إلى end(). في Android 10، تؤدي هذه الطرق إلى NullPointerException بدلاً من ذلك.

ملف Zip

في نظام التشغيل Android 10 والإصدارات الأحدث، ستكون دالة إنشاء ZipFile التي تأخذ الوسيطات من النوع File وint وCharset لا تعرض ZipException إذا كان ملف ZIP المقدم لا يحتوي على أي ملفات.

ZipOutputStream

في نظام التشغيل Android 10 والإصدارات الأحدث، finish() في "ZipOutputStream" لم يرمي ZipException إذا حاولت كتابة بث إخراج لملف ZIP لا يحتوي على أي ملفات.

التغييرات التي طرأت على الكاميرا

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

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

تتبُّع استخدام البطارية

بدءًا من الإصدار 10 من Android، يُعيد SystemHealthManager ضبط إحصاءات استخدام البطارية كلما تم فصل الجهاز عن مصدر الطاقة بعد حدث شارِج رئيسي. بوجه عام، يكون حدث الشحن الرئيسي إما: الجهاز مشحونة بالكامل أو تحول الجهاز من طاقته إلى النفاد تم شحنه.

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

إيقاف شعاع Android نهائيًا

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

تغيير في سلوك java.math.BigDecimal.stripTrailingZeros()

لم يعد BigDecimal.stripTrailingZeros() يحتفظ بالأصفار اللاحقة كـ في حالة خاصة إذا كانت قيمة الإدخال صفرًا.

التغييرات في سلوك java.util.regex.Matcher والنمط

تم تغيير نتيجة split() إلى أنها لم تعد تبدأ بـ String فارغ ("") في حال كان هناك تطابق بعرض صفري في بداية الإدخال. ويؤثر ذلك أيضًا في String.split(). على سبيل المثال، تعرض الدالة "x".split("") الآن القيمة {"x"}. بينما كان يعرض {"", "x"} على الإصدارات القديمة من Android. تعرض الدالة "aardvark".split("(?=a)" الآن مبلغ {"a", "ardv", "ark"} بدلاً من {"", "a", "ardv", "ark"}

تم أيضًا تحسين سلوك الاستثناء للوسيطات غير الصالحة:

  • طرح appendReplacement(StringBuffer, String) الآن IllegalArgumentException بدلاً من IndexOutOfBoundsException إذا كانت تنتهي عملية الاستبدال String بشرطة مائلة للخلف وحيدة، وهي غير قانونية. تشير رسالة الأشكال البيانية يتم طرح الاستثناء نفسه الآن إذا انتهى الاستبدال String بـ $. في السابق، لم يتم طرح أي استثناء في هذا السيناريو.
  • لم يعُد "replaceFirst(null)" يتصل بـ "reset()" على "Matcher" في حال طرح الرمز NullPointerException يتم طرح NullPointerException الآن أيضًا عند وجود غير مطابق. وفي السابق، لم يكن يتم التقاء باللعبة إلا عند وقوع مباراة.
  • رمية "start(int group)" و"end(int group)" و"group(int group)" مرة أخرى عام IndexOutOfBoundsException إذا كان فهرس المجموعة خارج الحدود. في السابق، طرحت هذه الطرق ArrayIndexOutOfBoundsException.

الزاوية التلقائية لـ GradentDrawable هي الآن TOP_BOTTOM

في Android 10، إذا حددت GradientDrawable بتنسيق XML ولا توفر قياسًا للزاوية أو اتجاه التدرج القيمة التلقائية على TOP_BOTTOM هذا التغيير يختلف عن الإصدارات السابقة من Android، حيث كان الوضع الافتراضي هو LEFT_RIGHT

كحل بديل، في حال التحديث إلى أحدث إصدار من AAPT2، تحدد الأداة قياس الزوايا على 0 للتطبيقات القديمة في حالة عدم وجود زاوية يتم تحديد القياس.

تسجيل الكائنات التسلسلية باستخدام SUID التلقائي

بدءًا من Android 7.0 (المستوى 24 من واجهة برمجة التطبيقات)، أجرى النظام الأساسي إصلاحًا إلى serialVersionUID التلقائي للترتيب . هذا الإصلاح لم يؤثر في التطبيقات التي تستهدف المستوى 23 أو أقل لواجهة برمجة التطبيقات.

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

وعلى وجه التحديد، يسجِّل النظام تحذيرًا في حال استيفاء جميع الشروط التالية:

  • يستهدف التطبيق المستوى 23 من واجهة برمجة التطبيقات أو المستويات الأدنى.
  • يتم تحديد فئة بشكل تسلسلي.
  • تستخدم الفئة المتسلسلة السمة serialVersionUID التلقائية، بدلاً من إعداد serialVersionUID صراحةً.
  • تختلف قيمة serialVersionUID التلقائية عن serialVersionUID. إذا استهدف التطبيق المستوى 24 أو أعلى لواجهة برمجة التطبيقات.

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

تغييرات java.io.FileChannel.map()

بدءًا من نظام التشغيل Android 10، FileChannel.map() غير متاح مع الملفات غير العادية، مثل /dev/zero، التي لا يمكن تغيير حجمها باستخدام truncate() الْلِّي قَبْلْ كِدَهْ الاصطدامات التي تسببت في إعادة إصدار نظام Android truncate()، ولكن Android 10 يعرض IOException. إذا كنت بحاجة إلى السلوك القديم، يجب استخدام رمز أصلي.