إصلاح Play Integrity على أندرويد المروت: ما الذي ما زال يعمل في 2026

هاتفك مروت، وGoogle Wallet يرفض الدفع، وتطبيق البنك يُغلق فور فتحه، وPlay Store يقول إن الجهاز غير معتمد. النصيحة التي تجدها في الغالب على الإنترنت هي "فلاش Play Integrity Fix". على هاتف قديم قد يكون هذا هو الجواب الصحيح. أما على هاتف حديث فغالبًا لا يكفي، والسبب تغيير أجرته Google على خوادمها، لا شيء فعله هاتفك.

الخلاصة السريعة. في أندرويد 12 وما دونه ما زالت الفحوص القديمة هي المعمول بها، والمسار الموثّق هو فورك مصان من Play Integrity Fix فوق Zygisk (بلا ضمان). أما في أندرويد 13 وما بعده فتشترط Google دليلًا مدعومًا بالعتاد على أن البوتلودر مقفل قبل أن تُرجع حكم device، وموديول يزوّر البصمة (fingerprint) وحده لا يستطيع تقديم هذا الدليل. خياراتك الواقعية هي روم المصنّع الأصلي مع إعادة قفل البوتلودر، أو موديول من فئة Tricky Store يعتمد على keybox صالح وقابل للإبطال، أو القبول بحكم basic فقط.¹²

تم فحص المصادر في 5 نوفمبر 2026. هذا دليل مبني على الوثائق. لم يختبر DroidRooter كل موديول أو هاتف مذكور هنا، وأرقام الإصدارات هي ما عرضته صفحات المشاريع في ذلك التاريخ.

انتقل إلى: ما الذي تغيّر · ماذا يتطلب كل حكم · أي موديول هو الحالي · اختر صفّك · خطوة بخطوة · Strong والـ keybox · إخفاء الروت · تأكد من النجاح · استكشاف الأخطاء · أندرويد 16 و17 · متى تتوقف · الأسئلة الشائعة

ما الذي تغيّر في هذا التحديث

قالت النسخة الأولى من هذه الصفحة إن الموديول المصان "يستعيد حكمي basic وdevice على معظم الهواتف". هذا تعميم زائد. فهو صحيح بالنسبة إلى basic، وبالنسبة إلى device في أندرويد 12 وما دونه، لكنه غير صحيح لهاتف أندرويد 13+ ببوتلودر مفتوح. تستبدل هذه النسخة ذلك الادعاء بصياغة Google نفسها، وتسمّي المشاريع الحالية وتؤرّخها بدل وصفها بأنها "الفوركات المحدّثة باستمرار"، وتضيف جدول قرار ومصفوفة استكشاف أخطاء وقسمًا عمّا لن نقوله لك.

ماذا يتطلب كل حكم من الأحكام الثلاثة في 2026

يُرجع Play Integrity حتى ثلاث تسميات للجهاز: basic (MEETS_BASIC_INTEGRITY) وdevice (MEETS_DEVICE_INTEGRITY) وstrong (MEETS_STRONG_INTEGRITY). غيّرت Google معناها في أندرويد 13 وما بعده ضمن طرحها في مايو 2025.²

Basic وdevice وstrong حسب إصدار أندرويد

المصادر: Google: Improved verdicts in Android 13 and later وGoogle: Play Integrity verdicts.²¹

هناك تفصيلان يغفل عنهما الناس. الأول أن تقدير Google نفسها لتغيير مايو 2025 كان انخفاضًا بنحو 0.4% في ردود device ونحو 14.5% في ردود strong، بالمتوسط عبر التطبيقات؛ وقد تكون بعض التطبيقات شهدت أكثر أو أقل.² والثاني أن "strong" في أندرويد 13+ ليس مفهوم keybox في تعريف Google. إنه device integrity مع مستوى رقعة أمنية. أما الـ keybox فآلية من المجتمع لملاحقة الجزء المدعوم بالعتاد، وسنشرحها لاحقًا.

ماذا يراه التطبيق فعلًا

افتراضيًا يحصل التطبيق على حكم device فارغ عندما ترى Google علامات هجوم (مثل hooking لـ API)، أو اختراقًا مثل الروت، أو جهازًا غير فعلي. أما تسميتا basic وstrong فاختياريتان: في أندرويد 13+ لا تُرجَعان إلا إذا فعّلهما المطوّر من Play Console وكان التطبيق الطالب قد ثُبّت أو حُدّث عبر Google Play. ويظل MEETS_DEVICE_INTEGRITY يُرجَع للتطبيقات غير المرخّصة من Play.¹²

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

لماذا يغيّر الروت والبوتلودر المفتوح الجواب

يتضمن key attestation في أندرويد بنية RootOfTrust فيها deviceLocked وverifiedBootState. ومنذ أندرويد 12 تستخدم الأجهزة Remote Key Provisioning، حيث تكون شهادات الـ attestation شهادات ECDSA P-256 لكل تطبيق وعمرها أقصر من الشهادات القديمة المزروعة في المصنع.³ ويُتوقع من الجهات المتحققة أن تفحص قائمة حالة إبطال الشهادات، وتقول وثائق Google للمطورين إن جذر attestation جديدًا بدأ توقيع السلاسل في 1 فبراير 2026.⁴

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

نصيحة Google نفسها لاختبار device integrity صريحة: تأكد من تثبيت روم المصنع (مثلًا بإعادة ضبط الجهاز) ومن أن البوتلودر مقفل.¹

أي موديول Play Integrity Fix هو الحالي فعلًا؟

الأصل اختفى

الموديول الأصلي من chiteroman لم يعد موجودًا على GitHub؛ فقد أرجع مستودعه الخطأ 404 في 5 نوفمبر 2026. ويقول README الخاص بفورك osm0sis إنه "Forked from chiteroman's Play Integrity Fix (PIF)" ويصف الأصل بأنه "no longer online". ولا تذكر أي من الصفحتين السبب، ولن نخمّن نحن.⁵¹⁰ أي دليل يرابط على zip الأصلي قديم.

هناك سلسلتان مصانتان نشطتان.

مقارنة موديولات Play Integrity Fix

المصادر: PlayIntegrityFork README وPIFork v19 release وinject-s v4.9 release وKernelSU module registry.⁵⁶⁷⁹

لا نرتّب هذه الموديولات حسب نسبة النجاح، لأننا لم نجد اختبارًا مستقلًا ولم نجرِ واحدًا. قارن بينها بما توثّقه: الصيانة، ومدراء الروت المدعومين، والحدود المعلنة. ثبّت فورك واحدًا، لا اثنين أبدًا. هذه قاعدتنا نحن لا اقتباس: يحذّر README الخاص بـ PIFork من أن الموديولات الأخرى، خصوصًا أي شيء يربط (hooks) Play Services، قد تُطلق كشف DroidGuard، واثنان من فوركات PIF يتنازعان التزوير نفسه هما أسهل طريق لحدوث ذلك.⁵

ما أضافه v19 إلى الصورة. تقول ملاحظات v19 إنه بسبب "a currently unknown further check added by Google" لا تنجح بعض الأجهزة إلا ببصمات Pixel Canary الخاصة بـ bluejay أو felix أو tangorpro (مع بصمات سلسلة Pixel 11 إذا استُخدم keybox من نوع RKP). هذا كلام المسؤول عن الصيانة عن سلوك لاحظه، وليس وثيقة من Google. وهو أيضًا مثال جيد على سبب تغيّر هذا المجال أسبوعيًا.⁶

مقارنة طبقات Zygisk

تحتاج السلسلتان إلى طبقة Zygisk. واختيارها يتوقف على مدير الروت لديك.

المصادر: Zygisk Next وReZygisk وNeoZygisk.¹⁶¹⁷¹⁸ يذكر README الخاص بـ Zygisk Next مديرَي KernelSU وMagisk فقط؛ ودعم APatch يأتي من README الخاص بـ PIFork، فراجع صفحة طبقة Zygisk نفسها لمدير الروت لديك قبل أن تعتمد عليها. أما كيف تتفاعل كل طبقة مع Shamiko وغيره من الموديولات فتجده مفصّلًا في دليل موديولات Magisk.

"Next" و"Inject" و"Fork": فك الرموز

• "Next" ليست نسخة من PIF. تعني عادةً Zygisk Next (طبقة Zygisk) أو KernelSU Next (مدير روت). لم نجد أي موديول اسمه "Play Integrity Fix Next".
• "Inject" اسم لسلسلة فروع من الموديول الأصلي. بحسب سجل KernelSU، يقوم inject-s على inject-manual، الذي يقوم على inject-vending، الذي يقوم على الفرع الرسمي inject؛ وتوصف فروع inject-vending وinject-manual الأقدم بأنها متوقفة.
• "Fork" هو PlayIntegrityFork.
• "Module" (موديول) تعني فقط إضافة لمدير الروت؛ والموديولات الحقيقية في الجدول أعلاه.

اختر صفّك أولًا

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

قبل أن تقرأ "أعد القفل": التحذيرات المهمة

إعادة القفل ليست تراجعًا مجانيًا. اقرأ هذه النقاط قبل أن تقرر.

• يمسح البيانات. إعادة القفل و"إعادة ضبط الجهاز" عند Google كلاهما يمسحان بيانات المستخدم في معظم الهواتف. خذ نسخة احتياطية أولًا، وتأكد أنها تُستعاد.
• ثبّت أولًا فيرموير المصنّع الكامل المطابق. لا تعد القفل أبدًا وعليك boot image معدّل أو روم مخصص. قد يترك ذلك الهاتف عاجزًا عن الإقلاع.
• Samsung: تفعيل Knox دائم، وSamsung Pay يرفض العمل بعد إعادة القفل، بحسب دليل فتح البوتلودر لدينا.
• بعض الشركات تربط حالة الفتح بالحسابات أو المناطق أو مفتاح OEM unlock. والإجراء يختلف من جهاز لآخر.
• إذا لم تكن متأكدًا، فاقرأ دليل فتح البوتلودر ومخاطر روت أندرويد أولًا، أو اسأل عن خدمة البوتلودر لدينا قبل أن تلمس أي شيء.

إذا كنت تحتاج مهمة روت لمرة واحدة وتريد إبقاء البوتلودر مقفلًا، فإن الروت المؤقت بدون فتح البوتلودر متاح لبعض الهواتف، لكنه محصور في إصدارات محددة مدعومة وقابلة للاستغلال. والجواب الصريح عن سؤال "هل سيعمل على هاتفي؟" هو في كثير من الأحيان: لا.

الإصلاح خطوة بخطوة

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

مسار Magisk

Magisk الحالي هو v31.1 (2026-10-25). تقول ملاحظات إصداره إن نافذة طلب الروت التفاعلية أُزيلت (تمنح الصلاحية مسبقًا من تبويب Superuser) وإن إخفاء التطبيق (إعادة تغليف الحزمة) أُزيل.¹⁹

1. فعّل Zygisk. تطبيق Magisk، الإعدادات (Settings)، فعّل Zygisk، ثم أعد التشغيل.
2. ثبّت فورك PIF واحدًا. تطبيق Magisk، تبويب Modules (الوحدات)، التثبيت من الذاكرة، اختر ملف zip من صفحة إصدارات المشروع نفسه، ثم أعد التشغيل.
3. حدّث البصمة. شغّل زر Action في الموديول. في PlayIntegrityFork يشغّل هذا autopif4 الذي يولّد بصمة Pixel Canary.
4. انتبه لملاحظة DenyList. يقول README الخاص بـ PIFork إن Google Play Services (com.google.android.gms) يجب ألا يكون في DenyList الخاصة بـ Magisk إذا كان Enforce DenyList مفعّلًا؛ والموديول يعالج ذلك بسكربتات، لكن مرة واحدة فقط لكل إعادة تشغيل.⁵
5. تحقق (انظر أدناه).

مسار KernelSU وKernelSU Next وAPatch

الإصدارات الحالية التي رأيناها بتاريخ 2026-11-05: KernelSU v3.3.1 (2026-10-12) وAPatch 11282 (2026-10-15).²⁰²¹ وبحسب README الخاص بـ PIFork تحتاج هذه المدراء إلى طبقة Zygisk منفصلة، لذلك:

1. ثبّت موديول Zygisk مستقلًا (Zygisk Next أو ReZygisk أو NeoZygisk)، ثم أعد التشغيل.
2. ثبّت فورك PIF واحدًا من شاشة الموديولات في المدير، ثم أعد التشغيل.
3. إذا فشل حكم device على هذه المدراء، فإصلاح README الخاص بـ PIFork هو: عطّل موديول Zygisk، أعد التشغيل، فعّله، ثم أعد التشغيل مرة أخرى.⁵

تجنّب SukiSU Ultra لهذا الغرض، بحسب ملاحظة PIFork عن حدّ العشر ثوانٍ لسكربتات Action.

تحديث البصمة، وما يجب ألا تشاركه

يولّد سكربت autopif4 بصمة جهاز عشوائية من أحدث Pixel Canary. ويقول README إن هذه البصمات تنتهي صلاحيتها تقريبًا كل ستة أسابيع، وإن بصمات Pixel Canary لم تعد قادرة وحدها على اجتياز DEVICE integrity، فأصبحت تناسب فقط إعدادات STRONG المقترنة بموديول من فئة Tricky Store. ويقول أيضًا إن البصمات العامة واسعة التداول تُحظر. لهذا السبب لا ينشر هذا المقال أي بصمات أو props؛ فأي دليل ينشرها سيتقادم خلال أيام.⁵

spoofVendingSdk: الحيلة القديمة غير المستقرة

يوثّق كلا الـ README خيارًا اسمه spoofVendingSdk يجعل Play Store يُبلغ عن مستوى SDK أقدم فتُرجع Google الأحكام القديمة. ويقول README الخاص بـ PIFork إن تركه مفعّلًا غير موصى به: فهو يُخلّ بسلوك Play Store إلى حدٍّ ما (إيماءة الرجوع وزر التنقل عند الجميع؛ وتسجيل الدخول والتنزيل عند مستويات SDK الأصلية الأعلى)، وقد يسبب أعطالًا ونسخًا خاطئة من التطبيقات، ويجب إعداد Play Store بالكامل أولًا وعدم مسح بياناته ما دام الخيار مفعّلًا. اعتبره مفتاح اختبار لا إعدادًا دائمًا.⁵⁷

Strong والـ keybox: ما الهش وما السبب

ما هو الـ keybox

الـ keybox، بالمعنى الذي يستخدمه README الخاص بـ Tricky Store، هو ملف من مفاتيح attestation المدعومة بالعتاد. ويقول README إنك تحتاج لأي شيء يتجاوز DEVICE integrity إلى hardware keybox غير مُبطَل (unrevoked).¹¹ وكلمة "غير مُبطَل" مهمة لأن شهادات attestation يمكن إبطالها؛ وGoogle تطلب من الجهات المتحققة فحص قائمة حالة الإبطال.⁴ قراءتنا نحن، لا كلام Google: المفاتيح المتداولة علنًا هي المرشح الأوضح للإبطال. ولا تنشر Google أي المفاتيح تُبطلها ولا متى.

فئة Tricky Store

تقع هذه الموديولات بين التطبيقات وخدمة key attestation في أندرويد. وكلها مشاريع منفصلة غير مرتبطة ببعضها، ولا شيء في وثائق أندرويد يزكّي أيًّا منها.

المصادر: Tricky Store وTrickyStoreOSS وTEESimulator وTEESimulator-RS وOh My Keymint.^1112131415 يسمّي README الخاص بـ PIFork هذه المشاريع الخمسة نفسها بوصفها الوحيدة التي يوصي بها لإعدادات DEVICE أو STRONG في أندرويد 13+. أما "شغّل واحدًا فقط" فنصيحتنا نحن: يقول TEESimulator إنه يحلّ محل الباقين، وموديولان يعدّلان الخدمة نفسها يجلبان المشاكل.

ملاحظة حياد. استخدام أيٍّ منها لجعل هاتف ببوتلودر مفتوح يبدو مقفلًا هو تزوير لـ hardware attestation. وقد يخالف شروط تطبيقات البنوك والألعاب وخدمات Google، وقد تُقيَّد الحسابات نتيجة لذلك. نحن نصف المشاريع؛ ولا نوصي بها كوسيلة "لاجتياز strong".

ادعاءان في README لا يتطابقان

يوحي README الخاص بـ Tricky Store بأن الإعداد الافتراضي يمكنه الوصول إلى DEVICE وأن الـ keybox مطلوب فيما يتجاوز ذلك. أما README الخاص بـ KOWX712 فيقول إنه في أندرويد 13+ يلزم keybox صالح مع موديول من فئة Tricky Store حتى لحكم Device، لأن "the Device verdict is now the same as the old Strong verdict". ونص Google يقول إن device يتطلب في أندرويد 13+ حكمًا إيجابيًا مدعومًا بالعتاد لـ verified boot. هذه النصوص لا تقول الشيء نفسه، ولا نستطيع أن نخبرك أيها يصح على هاتفك وإصدارك. اعتبر وثيقة Google هي القاعدة، والـ README ما يرويه كل مسؤول صيانة. وعبارة Tricky Store غير مؤرّخة ولا تتناول تغيير أندرويد 13+.¹¹⁸²

ما لن نقوله لك

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

قاعدة قرار أكثر أمانًا

1. إذا كنت تحتاج تطبيق بنك أو Wallet وdevice integrity شرط لا تنازل عنه: روم المصنّع الأصلي وبوتلودر مقفل. هذه نصيحة Google نفسها للاختبار، ويقدّم README الخاص بـ KOWX712 التوصية ذاتها للمستخدمين قليلي الخبرة الذين يحتاجون الاعتماد.¹⁸
2. إذا كنت تريد الروت وتطبيقاتك لا تحتاج إلا basic: ابقَ مروتًا وتقبّل أن التطبيقات الأشد صرامة قد ترفضك.
3. إذا كان لديك هاتف احتياطي: اعمل الروت على ذلك الهاتف وأبقِ هاتفك الأساسي على الروم الأصلي.

إخفاء الروت مشكلة مختلفة عن الحكم

الحكم هو ما تخبر به Google التطبيقَ. أما إخفاء الروت فيتعلق بما يستطيع التطبيق رؤيته على الهاتف نفسه. موديول PIF لا يخفي الروت: يقول inject-s إنه لم يُصنع لإخفاء الروت أو تفادي الكشف، وPIFork يزوّر فقط إلى عملية DroidGuard في Play Services.⁹⁵

أدوات مثل Shamiko وMagisk DenyList تعمل على المشكلة الثانية، وتوافقها مع كل طبقة Zygisk شأن دليل الموديولات لا شأن هذه الصفحة. وملاحظة عن الإصدار الحالي: أزال Magisk v31.1 إخفاء التطبيق (إعادة تغليف الحزمة)، فالنصيحة القديمة التي تقول لك أن تُخفي تطبيق Magisk قديمة لهذا الإصدار.¹⁹ وآخر إصدار Shamiko رأيناه في قائمة إصدارات LSPosed يعود إلى يونيو 2025، فراجع صفحة الموديول نفسه لمعرفة حالته الحالية. والتفاصيل في دليل موديولات Magisk.

تأكد أن الاجتياز نجح

1. Play Store: أيقونة الملف الشخصي، الإعدادات (Settings)، لمحة (About)، شهادة Play Protect (Play Protect certification). يجب أن تقول إن الجهاز معتمد. وقد تتأخر هذه الشاشة عن الحكم الحقيقي.
2. تطبيق فحص يستدعي Play Integrity API. لن نسمّي أيًّا منها، لأننا لم نتحقق من أن أيًّا منها مرجع موثوق. تطبيق الفحص لا يعني إلا بقدر طلبه، والتسميات الاختيارية تتوقف على كيفية إعداد الطلب والتثبيت.¹
3. تطبيقك الفعلي. افتح التطبيق الذي يهمك واستخدمه من البداية إلى النهاية.
4. أعد التشغيل واختبر مرة أخرى. الإصلاح الذي ينجح فقط بعد الفلاش مباشرة ليس إصلاحًا.

اقرأ الأسطر الثلاثة كما تعرّفها Google. قد يكون basic أخضر على هاتف أندرويد 13+ مروت بينما device أحمر. هذا هو النمط المتوقع، لا عطل في الموديول.

مصفوفة استكشاف الأخطاء

كل الصفوف أدناه مأخوذة من README الخاص بـ PlayIntegrityFork. و"<A13" تعني حكم أندرويد 12 وما دونه القديم.⁵

الإصلاحات التي تصمد يوم الاثنين قد تفشل يوم الجمعة، خصوصًا بعد تحديث Play Services أو الروم. وإذا تعطل إعداد كان يعمل بعد تحديث للنظام، فاستعادة boot image الصحيحة غالبًا تسبق أي إصلاح بالموديولات: انظر فشل تحديث OTA على هاتف مروت وكيف تحصل على صورة boot أو init_boot الصحيحة.

ما زلت عالقًا بعد محاولة واحدة نظيفة؟ هذه هي النقطة التي تتوقف عندها عن التخمين. أرسل لنا طراز هاتفك وإصدار أندرويد وطريقة الروت والتطبيقات التي تفشل بالضبط وسنخبرك بما هو واقعي قبل أن تدفع أي شيء.

أندرويد 16 و17: ماذا تتوقع

إليك ما تدعمه المصادر وما لا تدعمه.

• تصف وثائق Google أندرويد 13 وما بعده؛ ولا تستثني أندرويد 16 أو 17. فتنطبق قواعد أندرويد 13+ أعلاه.
• أضاف NeoZygisk v2.4 (2026-08-08) توقيعات zygote لأندرويد 17، ويدرج سجل KernelSU موديول inject-s بعبارة "Android 8-17". هذه حقائق توافق تخص الحقن (injection)، لا وعود بشأن الأحكام.¹⁸⁹
• لم نجد أي مصدر من Google يصف تغييرًا في Play Integrity خاصًا بأندرويد 16 مقابل 17. تزعم منشورات المنتديات أشياء مختلفة؛ ولم نكررها.

فإذا بحثت عن "اصلاح play integrity اندرويد 16"، فالجواب الصريح هو الجدول نفسه أعلاه، مع التحذير الإضافي بأن طبقات Zygisk تتأخر أحيانًا عن إصدار أندرويد جديد.

متى تتوقف (ومتى تطلب المساعدة)

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

• يحتاج التطبيق device أو strong في أندرويد 13+ وبوتلودرك مفتوح؛
• يعتمد الإصلاح على keybox لم تولّده بنفسك ولا تستطيع التحقق منه؛
• يستخدم التطبيق كشفه الخاص فوق Play Integrity وما زال يرفض الروت؛
• أنت على وشك إعادة القفل دون نسخة احتياطية مؤكدة ودون الفيرموير الكامل المطابق للمصنّع.

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

إذا أردت مساعدة: تبدأ خدمة إصلاح Play Integrity لدينا بفحص مجاني لطراز هاتفك وإصدار أندرويد وطريقة الروت والتطبيقات التي تفشل بالضبط. نخبرك بما هو واقعي قبل أن تدفع، بما في ذلك الحالة التي يكون فيها الجواب "هذا التطبيق لن ينجح على هذا الهاتف". وإذا مضى العمل، فتدفع مرة واحدة بعد أن يجتاز جهازك وتعمل تطبيقاتك، وإعادة الإصلاح مجانية لمدة 30 يومًا إذا كسر تحديث من Google Play أو من التطبيق ما أعددناه. لا نقدّم strong integrity كمُخرَج، ولا نعد أبدًا بأنه سيدوم. وإذا لم تعمل الروت بعد أو كنت تختار طريقة، فإن خدمة روت أندرويد هي نقطة البداية.

رسالة أولى مفيدة: الطراز، وإصدار أندرويد، ومدير الروت وإصداره، والتطبيقات التي تفشل بالضبط، وما تقوله شاشة شهادة Play Protect.

الخلاصة

Play Integrity على أندرويد المروت في 2026 ليس إصلاحًا واحدًا؛ إنه ثلاثة أسئلة. ما إصدار أندرويد لديك، وهل البوتلودر مقفل، وأي حكم يطلبه تطبيقك فعلًا؟

Basic واقعي. وdevice في أندرويد 12 وما دونه هو ما تستهدفه الفوركات المصانة. أما device في أندرويد 13 وما بعده فيحتاج بوتلودرًا مقفلًا، والحلول البديلة تتكئ على مفاتيح قابلة للإبطال وآثار جانبية ومخاطر شروط الخدمة. ويضيف strong شرط مستوى الرقعة فوق ذلك، ومن يعدك بأنه سيدوم يبالغ في البيع.

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

المصادر ووثائق المشاريع