بيانات محسَّنة في Android 13 والإصدارات الأحدث

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

ملخص التغييرات

يمكنك الاطّلاع على ملخّص تفصيلي للتغييرات والأسئلة الشائعة في وقت لاحق من هذا المستند. في ما يلي التغييرات التي طرأت على الحكم في مايو 2025:

ما هي التغييرات التأثير المقدَّر* الأجهزة
التغييرات التي تؤثر في جميع المطوّرين الذين يرسلون طلبات إلى واجهة برمجة التطبيقات Play Integrity API
استجابة بيان الجهاز: meets-device-integrity يجب الحصول على نتيجة إيجابية لعملية التشغيل المتحقَّق منه مع إثبات صحتها من خلال الأجهزة تأثير محدود لأنّ واجهة Play Integrity API تستخدم حاليًا إشارات أمان مستندة إلى الأجهزة على أجهزة Android 13 أو الإصدارات الأحدث (حوالي %0.4) ‫Android 13 والإصدارات الأحدث
استجابة "سلامة التطبيق": بيان التعرّف على التطبيق لم يتغيّر موقفي تأثير ضئيل، وسيعكس هذا التغيير في نتيجة الجهاز (حوالي %0.4) ‫Android 13 والإصدارات الأحدث
الردّ على تفاصيل الحساب: قرار ترخيص Play يجب أن يكون التطبيق الذي يطلب الإذن مثبّتًا أو محدَّثًا من خلال Google Play انخفاض طفيف في الردود المرخّصة (حوالي %2.5) الإصدار 6 من نظام التشغيل Android والإصدارات الأحدث
التغييرات التي تؤثّر فقط في مطوّري Play Console ومطوّري Play SDK Console الذين يستخدمون ميزات اختيارية
استجابة بيان الجهاز: meets-basic-integrity يجب أن يتضمّن مصادقة مفتاح منصة Android، ولكن يمكن أن تكون حالة التشغيل متحقَّقًا منها أو غير متحقَّق منها انخفاض طفيف في الردود الأساسية (حوالي %0.4) الإصدار 13 من نظام التشغيل Android والإصدارات الأحدث
الردّ على بيان سلامة الجهاز: meets-strong-integrity يجب أن يكون قد تم تثبيت تحديث أمان خلال العام الماضي انخفاض في الردود القوية (حوالي %14.5) الإصدار 13 من نظام التشغيل Android والإصدارات الأحدث
جميع الإشارات الاختيارية (باستثناء سمات الجهاز)** يجب أن يكون التطبيق الذي يطلب الإذن مثبّتًا أو محدَّثًا من خلال Google Play انخفاض في النسبة المئوية للردود التي تتضمّن إشارات اختيارية (حوالي %7) الإصدار 13 من نظام التشغيل Android والإصدارات الأحدث

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

**الإشارات الاختيارية (باستثناء سمات الجهاز) هي: meets-basic-integrity وmeets-strong-integrity ونشاط الجهاز الحديث وإيقاف الجهاز (إصدار تجريبي) وحالة "Play للحماية" واحتمالية اختراق التطبيق.

الأسئلة الشائعة

نظرة عامة

ما هي واجهة برمجة التطبيقات Play Integrity API؟

تساعدك واجهة برمجة التطبيقات Play Integrity API في تقييم مدى موثوقية بيئة تطبيق المستخدم من خلال الحصول على معلومات حول الجهاز والتطبيق والمستخدم، ما يتيح لك رصد أي إساءة استخدام أو هجمات محتملة والتعامل معها.

ما هي الإشارات التي توفّرها واجهة برمجة التطبيقات Play Integrity API؟

تتضمّن واجهة برمجة التطبيقات Play Integrity API هوية التطبيق الذي يرسل الطلب، وما إذا كان قد تم تثبيته من خلال Google Play، وما إذا كان الجهاز معتمدًا ويعمل بنظام Android. يتم توفير هذه الإشارات تلقائيًا. يمكنك قراءة هذه الإشارات على خادم الخلفية في تطبيقك وتحديد ما إذا كان تطبيقك سيردّ على هذه الإشارات وكيفية الردّ. يمكن لمطوّري Google Play الموافقة على تلقّي إشارات إضافية في عمليات تثبيت تطبيقاتهم على Play للاطّلاع على المزيد من المعلومات.

ما هي خدمة "مصادقة مفتاح منصة Android"؟

تتيح مصادقة مفتاح منصة Android للتطبيقات التحقّق من حالة الجهاز والحصول على إشارة قوية بشأن سلامة عملية التشغيل المستنِدة إلى الجهاز. يعتمد ذلك على مفتاح توفّره Google في مخزن المفاتيح المحمي بالأجهزة على الجهاز. تستخدم واجهة Play Integrity API حاليًا ميزة "إثبات صحة المفتاح" للحصول على إشارات أمان مستندة إلى الأجهزة على بعض الأجهزة، وسيتم دمجها بشكل أكبر على جميع الأجهزة التي تعمل بنظام التشغيل Android 13 أو الإصدارات الأحدث.

تغييرات الحكم

ما هي التغييرات التي تم إجراؤها على بيانات السلامة في واجهة Play Integrity API على أجهزة Android 13 أو الإصدارات الأحدث؟

تتطلّب واجهة برمجة التطبيقات Play Integrity API الآن إشارات أمان مستندة إلى الأجهزة لجميع بيانات السلامة:

  • إنّ meets-device-integrity نتيجة التعرّف على الجهاز هي مؤشر على أنّ الجهاز الذي يتم تشغيل التطبيق عليه هو جهاز Android حقيقي ومعتمَد. سيتطلّب هذا القرار قفل برنامج إقلاع الجهاز وأن يكون نظام التشغيل Android المحمَّل صورة معتمَدة من الشركة المصنّعة للجهاز.
  • يشير meets-strong-integrity إلى أنّ الجهاز معتمد وحقيقي ويعمل بنظام التشغيل Android ويتضمّن آخر تحديث أمان. سيتطلّب هذا الحكم توفُّر meets-device-integrity وتحديثات أمان خلال العام الماضي لجميع أقسام الجهاز، بما في ذلك تصحيح قسم نظام التشغيل Android وتصحيح قسم المورّد. وقد يتغيّر هذا الشرط في المستقبل.
  • تشير meets-basic-integrity نتيجة التعرّف على الجهاز إلى أنّ عملية التحقّق تمت على جهاز Android فعلي. يمكن أن يكون برنامج الإقلاع في الجهاز مقفلاً أو مفتوحًا، ويمكن أن تكون حالة التشغيل متحقَّقًا منها أو غير متحقَّق منها. وقد لا يكون الجهاز معتمَدًا، وفي هذه الحالة، لا يمكن أن تقدّم Google أي ضمانات بشأن الأمان أو الخصوصية أو توافق التطبيقات، ولا يمكنها أن تضمن أنّ الجهاز لا يعمل كخادم وكيل، مثلاً لإنشاء نسخة افتراضية من Android. يعني هذا أيضًا أنّ الأجهزة التي تم عمل روت لها مؤهَّلة لعرض meets-basic-integrity طالما أنّ مصادقة المفتاح متوفّرة.

لا تؤثّر هذه التغييرات في واجهة برمجة التطبيقات Play Integrity API على "ألعاب Play على الكمبيوتر"، والتي ستواصل عرض meets-virtual-integrity.

لماذا تم تغيير بيانات السلامة في واجهة Play Integrity API على أجهزة Android 13 أو الإصدارات الأحدث؟

كانت واجهة برمجة التطبيقات Play Integrity API تستخدم جزئيًا إشارات أمان مستندة إلى الأجهزة على الإصدار 12 من نظام التشغيل Android والإصدارات الأقدم. من خلال اشتراط توفّر أمان مستند إلى الأجهزة على أجهزة Android 13 والإصدارات الأحدث، تصبح بيانات السلامة التي تقدّمها واجهة Play Integrity API أكثر مرونة في مواجهة المهاجمين، وأكثر فعالية للتطبيقات، وأكثر حماية لخصوصية المستخدمين. يمكن للمطوّرين توقُّع التحسينات التالية على الأجهزة التي تعمل بالإصدار 13 من نظام التشغيل Android أو الإصدارات الأحدث:

  • انخفاض في إشارات الجهاز التي يجب جمعها وتقييمها لإنشاء الحكم التلقائي على خوادم Google بنسبة %90 تقريبًا ستظل الإشارات الاختيارية تتطلّب جمع إشارات إضافية.
  • تحسُّن في وقت استجابة القرار بنسبة تصل إلى% 80 لأسوأ الحالات في الطلبات العادية وبنسبة تصل إلى% 80 لجميع الطلبات الكلاسيكية للحصول على القرار التلقائي يمكن أن تؤدي الإشارات الاختيارية إلى زيادة وقت الاستجابة.
  • مستوى ثابت من الموثوقية والتوافق مع جميع أشكال أجهزة Android، بما في ذلك الهواتف والأجهزة اللوحية والهواتف القابلة للطي والتلفزيون وAndroid Auto وأجهزة Wear OS وChromeOS، مع توفير ميزة "إثبات صحة المفتاح".
  • توفير تمييز أكبر بين كل تصنيف جهاز في نتيجة التعرّف على الجهاز: meets-strong-integrity وmeets-device-integrity وmeets-basic-integrity

لن يتم تغيير بيان السلامة الذي تقدّمه واجهة Play Integrity API في برنامج "ألعاب Play على الكمبيوتر"، وسيكون هو نفسه على أجهزة Android 12 والإصدارات الأقدم كما هو على أجهزة Android 13 والإصدارات الأحدث.

كيف يمكنني تعديل منطق الخلفية في تطبيقي لكي تأخذ أحكام السلامة في الاعتبار إصدار حزمة تطوير البرامج (SDK) لنظام التشغيل Android؟

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

Kotlin

val deviceIntegrity =
  JSONObject(payload).getJSONObject("deviceIntegrity")
val sdkVersion =
  if (deviceIntegrity.has("deviceAttributes")) {
    deviceIntegrity.getJSONObject("deviceAttributes").getInt("sdkVersion")
  } else {
    0
  }

if (sdkVersion >= 30) {
  // Provide Android R+ specific experience to the user.
}

Java

JSONObject deviceIntegrity =
  new JSONObject(payload).getJSONObject("deviceIntegrity");
int sdkVersion =
  deviceIntegrity.has("deviceAttributes")
    ? deviceIntegrity.getJSONArray("deviceAttributes").getInt("sdkVersion")
    : 0;

if (sdkVersion >= 30) {
  // Provide Android R+ specific experience to the user.
}

كيف يمكنني استخدام تعريف التصنيف القديم meets-strong-integrity في جميع إصدارات حزمة تطوير البرامج (SDK) لنظام التشغيل Android؟

يمكنك تحقيق ذلك من خلال تعديل منطق الخلفية في تطبيقك لاستخدام meets-strong-integrity عندما يكون الجهاز يعمل بإصدار Android 13 أو إصدار أقدم، واستخدام meets-device-integrity عندما يكون الجهاز يعمل بإصدار Android 13 أو إصدار أحدث، وذلك باستخدام حقل سمات الجهاز الجديد في البيان الذي يتضمّن إصدار حزمة تطوير البرامج (SDK) لنظام التشغيل Android. في ما يلي مثال على كيفية إجراء ذلك:

Kotlin

val deviceRecognitionVerdict =
  if (deviceIntegrity.has("deviceRecognitionVerdict")) {
    deviceIntegrity.getJSONArray("deviceRecognitionVerdict").toString()
  } else {
    ""
  }

val deviceIntegrityToCheckFor =
  sdkVersion < 33 ? "MEETS_STRONG_INTEGRITY" : "MEETS_DEVICE_INTEGRITY";

if (deviceRecognitionVerdict.contains(deviceIntegrityToCheckFor)) {
  // Looks good!
}

Java

JSONObject deviceIntegrity =
  new JSONObject(payload).getJSONObject("deviceIntegrity");
String deviceRecognitionVerdict =
  deviceIntegrity.has("deviceRecognitionVerdict")
    ? deviceIntegrity.getJSONArray("deviceRecognitionVerdict").toString()
    : "";

String deviceIntegrityToCheckFor =
  sdkVersion < 33 ? "MEETS_STRONG_INTEGRITY" : "MEETS_DEVICE_INTEGRITY";

if (deviceRecognitionVerdict.contains(deviceIntegrityToCheckFor)) {
  // Looks good!
}

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

ما هي التغييرات الأخرى التي تم إجراؤها على الأحكام؟

نستثمر باستمرار في جعل الإشارات الحالية في واجهة برمجة التطبيقات Play Integrity API أكثر موثوقية، ونطلق بشكل دوري ميزات جديدة لمساعدة المطوّرين في التعامل مع التهديدات الناشئة وحالات الاستخدام الجديدة. تشمل التحسينات الأخرى التي أجريناها على بيانات السلامة ما يلي:

  • الردّ المرخَّص من Play: لكي تعرض واجهة برمجة التطبيقات Play Integrity API ردًا مرخَّصًا من Play، يجب أن يكون التطبيق الذي يرسل الطلب مثبَّتًا أو محدَّثًا من خلال Google Play. يحلّ هذا التغيير بعض الحالات الحدّية ويسهّل على المطوّرين تفسير الرد.
  • مدى توفّر الإشارات الاختيارية: تتطلّب جميع الإشارات الاختيارية المتاحة للمطوّرين الذين يستخدمون Google Play Console أو Play SDK Console (باستثناء سمات الجهاز) أن يكون التطبيق المرسِل للطلب مثبّتًا أو محدّثًا من خلال Google Play على الإصدار 13 من نظام التشغيل Android أو الإصدارات الأحدث. ويشمل ذلك meets-strong-integrity وmeets-basic-integrity وأحدث أنشطة الجهاز وميزة "تذكُّر الجهاز" (ميزة تجريبية) ونتيجة تقييم مخاطر الوصول إلى التطبيقات ونتيجة تقييم Play Protect. لقد وحّدنا جميع طلبات Play Integrity API الأخرى لتلقّي بيانات التحقّق من الجهاز (مع العلامة meets-device-integrity فقط)، وبيانات التحقّق من أداة التثبيت، وبيانات التحقّق من سلامة التطبيق، وسمات الجهاز (في حال تفعيلها).
  • تغييرات في بيانات السلامة لأجهزة معيّنة: تعمل واجهة برمجة التطبيقات Play Integrity API تلقائيًا على تغيير بيانات السلامة للأجهزة في المزيد من السيناريوهات لحماية التطبيقات في وقت مبكر على جميع إصدارات حزمة تطوير البرامج (SDK) لنظام Android، مثلاً عند توفّر دليل على نشاط مفرط أو اختراق المفتاح. ويشمل ذلك إمكانية أن يعتمد Play على إشارات أخرى لإنشاء نتائج مؤقتة للأجهزة للمستخدمين عندما لا تتوفّر إشارات مستندة إلى الأجهزة. ننصح المطوّرين باستخدام مربّعات الحوار الخاصة بإجراءات الإصلاح في Play داخل التطبيق أو توجيه المستخدمين إلى تطبيق "متجر Play" لحلّ المشاكل المتعلّقة بنتيجة تقييم السلامة. وبمرور الوقت، ستتعامل مربّعات الحوار هذه مع المزيد من السيناريوهات وستتضمّن إرشادات محدّدة للمستخدمين توضّح لهم ما عليهم إصلاحه استنادًا إلى أجهزتهم أو حساباتهم المحدّدة.

كيف يمكنني الإبلاغ عن مشاكل في أحكام السلامة؟

للإبلاغ عن مشاكل في الردود الواردة من واجهة برمجة التطبيقات Play Integrity API، سواء كانت المشكلة متعلقة بالبيانات السابقة أو الجديدة، اتّبِع التعليمات الواردة في صفحة الدعم.

مدى التوفّر

ما هي المتطلبات اللازمة لعمل واجهة برمجة التطبيقات Play Integrity API؟

تتطلّب واجهة برمجة التطبيقات Play Integrity API تثبيت "متجر Google Play" و"خدمات Google Play" على الجهاز، ويشمل ذلك أجهزة Android و"ألعاب Google Play على الكمبيوتر". تتطلّب الطلبات الكلاسيكية الإصدار 4.4 من نظام التشغيل Android (المستوى 19 من واجهة برمجة التطبيقات) أو إصدارًا أحدث، بينما تتطلّب الطلبات العادية الإصدار 5.0 من نظام التشغيل Android (المستوى 21 من واجهة برمجة التطبيقات) أو إصدارًا أحدث. على الأجهزة التي تعمل بنظام التشغيل Android 13 (المستوى 33 لواجهة برمجة التطبيقات) والإصدارات الأحدث، ستتوفّر واجهة برمجة التطبيقات Play Integrity API بمستوى الموثوقية والدعم نفسه على جميع أشكال أجهزة Android مع ميزة "إثبات صحة المفتاح"، بما في ذلك الأجهزة الجوّالة والأجهزة اللوحية والأجهزة القابلة للطي والتلفزيون وAuto وWear OS وChromeOS.

لماذا تقدّم واجهة برمجة التطبيقات Play Integrity API بيانات سلامة مختلفة للأجهزة المختلفة؟

توفّر واجهة برمجة التطبيقات Play Integrity API بيانات متعددة عن الأجهزة لتلبية احتياجات المطوّرين الذين لديهم حالات استخدام مختلفة ومستويات تحمّل مختلفة للمخاطر، ولإتاحة وضع استراتيجية تنفيذ على عدة مستويات. على سبيل المثال، عندما يكون التطبيق والجهاز أكثر موثوقية، يمكن للمطوّر تبسيط خطوات التحقّق من المستخدم، بينما عندما يكون الجهاز غير معروف، قد يطلب المطوّر إجراء تحقّق إضافي من المستخدم قبل تنفيذ إجراءات محمية أو حساسة. ويمكن أن تكون هذه الطريقة فعّالة للحدّ من إساءة الاستخدام والهجمات.

ما هو جهاز Android المعتمَد؟

جهاز Android معتمَد (يُعرف أيضًا باسم جهاز Android معتمَد من &quot;Play للحماية&quot;) هو جهاز يعمل ببرنامج يمكن توقّعه وقد اجتاز مئات اختبارات التوافق من Google، ويتوافق مع نموذج الأمان والأذونات في Android، وتم شحنه مع مجموعة ميزات مكافحة البرامج الضارة من &quot;Google Play للحماية&quot;. عندما تتمكّن واجهة برمجة التطبيقات Play Integrity API من التحقّق من أنّ الجهاز هو جهاز Android حقيقي ومعتمد، ستعرض الرد meets-device-integrity في بيان السلامة الخاص بالتعرّف على الجهاز.

ما هو جهاز meets-basic-integrity؟

تعرض واجهة برمجة التطبيقات Play Integrity API أيضًا استجابة اختيارية في نتيجة الجهاز، meets-basic-integrity. إذا كان الجهاز يعرض النتيجة meets-basic-integrity فقط بدون meets-device-integrity أو meets-strong-integrity، يعني ذلك أنّه لا يمكن التحقّق من نظام التشغيل Android، ولكن تتوفّر مصادقة المفتاح. يشير ذلك إلى أنّ عملية التحقّق تمت على جهاز فعلي يعمل بنظام التشغيل Android، ولكن لا يمكن لشركة Google تقديم ضمانات بشأن أمان الجهاز أو خصوصيته أو توافقه مع التطبيقات، ولا يمكنها ضمان أنّ الجهاز لا يعمل كخادم وكيل، مثلاً لنسخة افتراضية من Android. واستنادًا إلى حالات الاستخدام ومستوى تحمّل المخاطر لدى المطوّرين، يمكنهم تحديد الطريقة التي يريدون أن يعمل بها تطبيقهم على هذه الأجهزة.

هل يمكن لأي مطوّر استخدام واجهة برمجة التطبيقات Play Integrity API؟

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

هل يمكن لأي مطوّر استخدام خدمة "إثبات صحة مفتاح النظام الأساسي على Android"؟

نعم، يمكن لأي مطوّر تطبيقات Android استخدام خدمة &quot;إثبات صحة مفتاح منصة Android&quot; للحصول على سجلّ إثبات صحة المفتاح، ويمكنه التحقّق من هذا السجلّ باستخدام الشهادة العلنية لمفتاح الجذر الخاص بخدمة إثبات الصحة من Google. توفّر واجهة برمجة التطبيقات Play Integrity API للمطوّرين مزايا شهادة صحة المفتاح وميزات إضافية بدون الحاجة إلى التعامل مع تعقيدات دمج شهادة صحة المفتاح بأنفسهم.

التنفيذ

كيف يستخدم المطوّرون بيانات السلامة الصادرة عن واجهة برمجة التطبيقات Play Integrity API؟

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

هل تحظر واجهة برمجة التطبيقات Play Integrity API المستخدمين أو الأجهزة؟

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

ماذا على المستخدمين أن يفعلوا إذا لم يجتز جهازهم عمليات التحقّق من الجهاز التي تجريها واجهة برمجة التطبيقات Play Integrity API؟

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