تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يتيح نظام التشغيل Android أدوات متعددة لتصحيح أخطاء الذاكرة. لكلّ منهما مزايا وعيوب، لذا يُرجى قراءة ما يلي لتحديد الخيار الأنسب لحالة الاستخدام. تقدّم لك هذه المستندات نظرة عامة على الأدوات المتاحة حتى تتمكّن من تحديد الأدوات التي تريد البحث فيها بشكل أكبر، ولكنّها تهدف إلى أن تكون موجزة، لذا ننصحك بقراءة المستندات الخاصة بكل أداة للحصول على التفاصيل.
اللغة الآمنة من حيث إدارة الذاكرة هي الطريقة الوحيدة لتجنُّب أخطاء الذاكرة والحدّ منها بشكل كامل. يمكن أن تساعدك الأدوات الأخرى في هذه الصفحة على جعل الرموز البرمجية غير الآمنة للذاكرة أكثر أمانًا وموثوقية، ولكن استخدام لغة آمنة للذاكرة يزيل فئة المشاكل بأكملها.
اللغتان المتوافقتان رسميًا مع Android واللتان توفّران أمانًا للذاكرة هما Java وKotlin.
ويكون تطوير معظم تطبيقات Android أسهل باستخدام إحدى هاتين اللغتَين.
مع ذلك، هناك مطوّرو تطبيقات يرسلون رمزًا مكتوبًا بلغة Rust، وإذا كنت تقرأ هذه الصفحة، من المحتمل أنّ لديك سببًا وجيهًا لاستخدام الرمز البرمجي الأصلي (إمكانية النقل أو الأداء أو كليهما). Rust هي الخيار الأفضل للرمز البرمجي الأصلي الآمن للذاكرة على Android. قد لا يتمكّن فريق NDK من مساعدتك في حل المشاكل التي تواجهها إذا اخترت هذا المسار، ولكننا مهتمون بالاستماع إلى ملاحظاتك.
PAC/BTI
مصادقة المؤشر وتعريف هدف الفرع،
المعروفة أيضًا باسم PAC/BTI، هما أداتان للتخفيف من المخاطر ومناسبتان للاستخدام في مرحلة الإنتاج.
وعلى الرغم من أنّها تقنيات منفصلة، يتم التحكّم فيها باستخدام علامة الترجمة البرمجية نفسها، لذا يتم استخدامها معًا دائمًا.
وتتوافق هذه الميزات مع الأجهزة القديمة التي لا تتوافق معها، لأنّ التعليمات الجديدة المستخدَمة لا تؤدي أي وظيفة على الأجهزة القديمة. ويجب أيضًا أن يكون لديك إصدار حديث من النواة وإصدار حديث من نظام التشغيل.
يساعدك البحث عن paca وbti في /proc/cpuinfo في معرفة ما إذا كان لديك جهاز جديد
بما يكفي ونواة جديدة بما يكفي. يتضمّن نظام التشغيل Android 12 (المستوى 31 من واجهة برمجة التطبيقات) دعمًا ضروريًا لمساحة المستخدم.
الإيجابيات:
يمكن تفعيلها في جميع الإصدارات بدون التسبّب في حدوث مشاكل على الأجهزة أو النواة القديمة (ولكن تأكَّد من أنّك اختبرتها فعليًا على جهاز/نواة/نظام تشغيل يتوافق معها).
السلبيات:
متاح فقط لتطبيقات 64 بت
لا يقلّل من الأخطاء على الأجهزة التي لا تتوافق معه
زيادة في حجم الرمز بنسبة% 1
GWP-Asan
يمكن استخدام GWP-ASan لرصد أخطاء الذاكرة في
المجال، ولكن معدّل أخذ العينات منخفض جدًا بحيث لا يمكن أن يكون وسيلة فعّالة للحدّ من هذه الأخطاء.
الإيجابيات:
لا يوجد حمل كبير على وحدة المعالجة المركزية أو الذاكرة
سهولة النشر: لا يتطلّب إعادة إنشاء الرمز البرمجي الأصلي
تعمل مع تطبيقات 32 بت
السلبيات:
يتطلّب معدّل أخذ العيّنات المنخفض عددًا كبيرًا من المستخدمين للعثور على الأخطاء بفعالية
لا يرصد سوى أخطاء الذاكرة المؤقتة، وليس أخطاء الذاكرة المخصّصة
HWASan
أداة تنظيف عناوين الأجهزة، المعروفة أيضًا باسم HWASan، هي الأداة الأنسب لرصد أخطاء الذاكرة أثناء الاختبار. تكون هذه الميزة مفيدة جدًا عند استخدامها مع الاختبارات المبرمَجة، خاصةً إذا كنت تجري اختبارات غامضة، ولكن قد يكون من الممكن استخدامها أيضًا على الهواتف المتطورة في إعدادات تجريبية، وذلك حسب احتياجات أداء تطبيقك.
الإيجابيات:
ما مِن نتائج إيجابية خاطئة
يرصد فئات إضافية من الأخطاء التي لا يمكن لـ ASan رصدها (استخدام الذاكرة المخصّصة في المكدّس بعد إرجاعها)
معدّل أقل للحالات السلبية الخاطئة مقارنةً بـ MTE (حالة واحدة من 256 حالة مقابل حالة واحدة من 16 حالة)
استخدام ذاكرة أقل من ASan، وهو البديل الأقرب
السلبيات:
زيادة كبيرة في استخدام وحدة المعالجة المركزية (حوالي 100%) وحجم الرمز البرمجي (حوالي 50%) والذاكرة (من 10% إلى 35%)
حتى الإصدار 34 من واجهة برمجة التطبيقات وNDK r26، يتطلّب ذلك تثبيت صورة متوافقة مع HWASan
معدّل النتائج السلبية الخاطئة هو 1 من 16 مقارنةً بمعدّل 1 من 256 في HWASan
متاح فقط لتطبيقات 64 بت
يتطلّب ذلك إنشاء مكتبات منفصلة لاستهداف الأجهزة التي تم تفعيل إضافة وضع علامات الذاكرة (MTE) عليها والأجهزة التي لم يتم تفعيلها عليها
ASan
Address sanitizer، المعروفة أيضًا باسم ASan، هي الأداة الأقدم والأكثر توفّرًا من بين الأدوات المتاحة. وهي مفيدة في رصد أخطاء الذاكرة أثناء الاختبار وتصحيح الأخطاء التي تؤثر فقط في الأجهزة القديمة التي لا تتوفّر فيها أي من الأدوات الأخرى. استخدام HWASan كلما أمكن ذلك
الإيجابيات:
متاحة على نطاق واسع قد يعمل على الأجهزة القديمة التي تعمل بإصدار KitKat
لا يتم تسجيل نتائج إيجابية أو سلبية خاطئة عند استخدامها بشكل صحيح
السلبيات:
صعوبة إنشاء الحزمة وتغليفها بشكل صحيح
أعلى تكلفة إضافية بين جميع الخيارات: %100 تقريبًا من وحدة المعالجة المركزية، و% 50 تقريبًا من حجم الرمز، و% 100 تقريبًا من استخدام الذاكرة
لم يعُد متاحًا
يحتوي على أخطاء معروفة لن يتم إصلاحها
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-08-21 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-08-21 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Memory error debugging and mitigation\n\nAndroid supports multiple tools for debugging memory errors. There are tradeoffs\nto each, so read below to decide which is best for your use case. This doc gives\nyou an overview of the tools available so you can decide which to investigate\nfurther, but it aims to be succinct, so read the tool-specific docs for details.\n\ntl;dr\n-----\n\n- Use a [memory safe language](#memory-safe-languages) whenever possible to make memory errors impossible\n- Always use [PAC/BTI](#pacbti) to mitigate ROP/JOP attacks\n- Always use [GWP-ASan](#gwp-asan) for detecting rare memory errors in production\n- Use [HWASan](#hwasan) to detect memory errors during testing\n- [MTE](#mte) is available as an option on [select devices](/ndk/guides/arm-mte#hwsupport).\n- Use [ASan](#asan) during testing only as a last resort\n\nMemory safe languages\n---------------------\n\nA memory safe language is the only way to entirely avoid and mitigate memory\nerrors. The other tools on this page can help you make your memory unsafe code\nsafer and more reliable, but using a memory safe language eliminates the entire\nclass of problems.\n\nThe officially supported memory safe languages for Android are Java and Kotlin.\nMost Android applications are easier to develop in one of those languages.\n\nThat said, there are app developers shipping code written in Rust, and if you're\nreading this page you probably do have a good reason to need native code\n(portability, performance, or both). Rust is the best choice for memory safe\nnative code on Android. The NDK team is not necessarily able to help you with\nthe problems you face if you go that route, but we are interested in\n[hearing about them](https://github.com/android/ndk/discussions)!\n\nPAC/BTI\n-------\n\n[Pointer Authentication and Branch Target Identification](/ndk/guides/abis#armv9_enabling_pac_and_bti_for_cc),\nalso known as PAC/BTI, are mitigation tools suitable for use in production.\nThough separate technologies, they are controlled by the same compiler flag so\nare always used together.\n\nThese features are backward compatible with devices that don't support them\nbecause the new instructions used are no-ops on earlier devices. It's also\nnecessary to have a new enough kernel and a new enough version of the OS.\nLooking for `paca` and `bti` in `/proc/cpuinfo` shows you whether you have new\nenough hardware and a new enough kernel. Android 12 (API 31) has the necessary\nuserspace support.\n| **Key Point:** Good mitigation requires defense in depth. Consider combining PAC/BTI with [MTE](#mte).\n\nPros:\n\n- Can be enabled in all builds without causing problems on older devices or kernels (but make sure you've actually tested on a device/kernel/OS combination that *does* support it!)\n\nCons:\n\n- Only available for 64-bit apps\n- Doesn't mitigate errors on devices that don't support it\n- 1% code size overhead\n\nGWP-Asan\n--------\n\n[GWP-ASan](/ndk/guides/gwp-asan) can be used to detect memory errors in the\nfield, but the sampling rate is too low to be an effective mitigation.\n\nPros:\n\n- No significant CPU or memory overhead\n- Trivial to deploy: does not require rebuilding native code\n- Works for 32-bit apps\n\nCons:\n\n- Low sampling rate requires a large number of users to find bugs effectively\n- Only detects heap errors, not stack errors\n\nHWASan\n------\n\n[Hardware address sanitizer](/ndk/guides/hwasan), also known as HWASan, is the\nbest fit for catching memory errors during testing. It's most useful when used\nwith automated testing, especially if you're running fuzz tests, but depending\non your app's performance needs it may also be usable on high end phones in a\ndogfood setting.\n\nPros:\n\n- No false positives\n- Detects additional classes of errors that ASan cannot (stack use after return)\n- Lower rate of false negatives than MTE (1 in 256 vs 1 in 16)\n- Lower memory overhead than ASan, its closest alternative\n\nCons:\n\n- Significant CPU (\\~100%), code size (\\~50%), and memory (10% - 35%) overhead\n- Until API 34 and NDK r26, requires flashing a HWASan compatible image\n- Only works on 64-bit apps\n\nMTE\n---\n\n[Memory tagging extension](/ndk/guides/arm-mte), also known as MTE, is a lower-\ncost alternative to HWASan. In addition to debugging and testing capabilities,\nit can be used to detect and mitigate memory corruption in production. If you\nhave [the hardware to test MTE builds](/ndk/guides/arm-mte#check), you should\nenable it.\n\nPros:\n\n- Low enough overhead to be tolerable in production for many apps\n- No false positives\n- Does not require rebuilding code to detect heap errors (but does to detect stack errors)\n\nCons:\n\n- There are no commercially available devices with MTE enabled by default in 2024, but Arm's documentation explains [how to enable MTE for testing on Pixel 8/Pixel 8 Pro](https://learn.arm.com/learning-paths/smartphones-and-mobile/mte_on_pixel8/).\n- False negative rate of 1 in 16 vs HWASan's 1 in 256\n- Only available for 64-bit apps\n- Requires building separate libraries for targeting both MTE-enabled and non- MTE enabled devices\n\nASan\n----\n\n[Address sanitizer](/ndk/guides/asan), also known as ASan, is the oldest and\nmost widely available of the tools available. It is useful for catching memory\nerrors during testing and debugging issues that only affect old devices where\nnone of the other tools are available. **Whenever possible, prefer HWASan.**\n| **Deprecated:** ASan has been superseded by the other tools on this page, so is no longer receiving active development or support. ASan should only be used when HWASan is not an option.\n\nPros:\n\n- Widely available. May work on devices as old as KitKat\n- No false positives or negatives when used correctly\n\nCons:\n\n- Difficult to build and package correctly\n- Highest overhead of all options: \\~100% CPU, \\~50% code size, \\~100% memory use\n- No longer supported\n- Has known bugs that won't be fixed"]]
