با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
اندروید از چندین ابزار برای رفع اشکال خطاهای حافظه پشتیبانی می کند. برای هرکدام معاوضه هایی وجود دارد، بنابراین برای تصمیم گیری در مورد بهترین مورد برای استفاده شما، زیر را بخوانید. این سند به شما یک نمای کلی از ابزارهای موجود می دهد تا بتوانید تصمیم بگیرید که کدامیک را بیشتر بررسی کنید، اما هدف آن مختصر است، بنابراین برای جزئیات، اسناد مخصوص ابزار را بخوانید.
tl;dr
برای غیرممکن کردن خطاهای حافظه تا حد امکان از یک زبان امن برای حافظه استفاده کنید
همیشه از PAC/BTI برای کاهش حملات ROP/JOP استفاده کنید
همیشه از GWP-ASan برای تشخیص خطاهای حافظه نادر در تولید استفاده کنید
از HWASan برای تشخیص خطاهای حافظه در طول آزمایش استفاده کنید
از ASan در طول آزمایش فقط به عنوان آخرین راه حل استفاده کنید
زبان های ایمن حافظه
زبان امن حافظه تنها راه برای جلوگیری و کاهش خطاهای حافظه است. سایر ابزارهای موجود در این صفحه می‌توانند به شما کمک کنند تا کد ناامن حافظه خود را ایمن‌تر و قابل اعتمادتر کنید، اما استفاده از یک زبان ایمن حافظه کل مشکلات را برطرف می‌کند.
زبان‌های ایمن حافظه رسمی پشتیبانی شده برای اندروید جاوا و کاتلین هستند. توسعه اکثر برنامه های اندروید به یکی از آن زبان ها آسان تر است.
با این اوصاف، کدهای ارسال برنامه‌نویسان برنامه وجود دارد که به زبان Rust نوشته شده‌اند، و اگر در حال خواندن این صفحه هستید، احتمالاً دلیل خوبی برای نیاز به کد بومی (قابل حمل، عملکرد یا هر دو) دارید. Rust بهترین انتخاب برای کد بومی ایمن حافظه در اندروید است. تیم NDK لزوماً نمی تواند به شما در رفع مشکلاتی که در صورت رفتن به آن مسیر با آن مواجه می شوید کمک کند، اما ما علاقه مندیم در مورد آنها بشنویم !
PAC/BTI
احراز هویت اشاره‌گر و شناسایی هدف شاخه ، که با نام PAC/BTI نیز شناخته می‌شود، ابزارهای کاهشی مناسب برای استفاده در تولید هستند. اگرچه فناوری‌های مجزا هستند، اما توسط یک پرچم کامپایلر کنترل می‌شوند، بنابراین همیشه با هم استفاده می‌شوند.
این ویژگی‌ها با دستگاه‌هایی که از آنها پشتیبانی نمی‌کنند سازگار هستند، زیرا دستورالعمل‌های جدید مورد استفاده در دستگاه‌های قبلی غیرفعال هستند. همچنین لازم است یک هسته به اندازه کافی جدید و یک نسخه کافی جدید از سیستم عامل داشته باشید. جست‌وجوی paca و bti در /proc/cpuinfo به شما نشان می‌دهد که آیا سخت‌افزار به اندازه کافی جدید و یک هسته جدید به اندازه کافی دارید. اندروید 12 (API 31) پشتیبانی لازم از فضای کاربری را دارد.
جوانب مثبت:
می‌تواند در همه بیلدها بدون ایجاد مشکل در دستگاه‌ها یا هسته‌های قدیمی‌تر فعال شود (اما مطمئن شوید که واقعاً روی ترکیبی از دستگاه/هسته/سیستم‌عامل که از آن پشتیبانی می‌کند تست کرده‌اید!)
معایب:
فقط برای برنامه های 64 بیتی موجود است
خطاها را در دستگاه هایی که از آن پشتیبانی نمی کنند، کاهش نمی دهد
سربار اندازه کد 1٪
GWP-Asan
GWP-ASan را می توان برای تشخیص خطاهای حافظه در میدان مورد استفاده قرار داد، اما نرخ نمونه برداری برای کاهش موثر آن بسیار کم است.
جوانب مثبت:
بدون سربار CPU یا حافظه قابل توجهی
بی اهمیت برای استقرار: نیازی به بازسازی کد بومی ندارد
برای برنامه های 32 بیتی کار می کند
معایب:
نرخ نمونه برداری پایین به تعداد زیادی از کاربران نیاز دارد تا اشکالات را به طور موثر پیدا کنند
فقط خطاهای پشته را تشخیص می دهد، نه خطاهای پشته
HWASan
ضدعفونی کننده آدرس سخت افزاری که با نام HWASan نیز شناخته می شود، بهترین گزینه برای تشخیص خطاهای حافظه در طول آزمایش است. زمانی که با تست خودکار استفاده می شود بسیار مفید است، به خصوص اگر در حال اجرای تست های فازی هستید، اما بسته به نیازهای عملکرد برنامه شما ممکن است در تلفن های پیشرفته در تنظیمات آزمایشی نیز قابل استفاده باشد.
جوانب مثبت:
بدون مثبت کاذب
کلاس های اضافی از خطاهایی را که ASan نمی تواند شناسایی کند (استفاده از پشته پس از بازگشت)
نرخ منفی کاذب کمتر از MTE (1 در 256 در مقابل 1 در 16)
سربار حافظه کمتر از ASan، نزدیکترین جایگزین آن
معایب:
CPU قابل توجه (~ 100٪)، اندازه کد (~50٪) و حافظه (10٪ - 35٪) سربار
تا API 34 و NDK r26، نیاز به فلش کردن یک تصویر سازگار با HWASan دارد.
فقط روی برنامه های 64 بیتی کار می کند
MTE
افزونه برچسب‌گذاری حافظه ، که به عنوان MTE نیز شناخته می‌شود، جایگزین ارزان‌تری برای HWASan است. علاوه بر قابلیت اشکال زدایی و تست، می توان از آن برای شناسایی و کاهش خرابی حافظه در تولید استفاده کرد. اگر سخت افزاری برای آزمایش ساخت های MTE دارید، باید آن را فعال کنید.
جوانب مثبت:
سربار به اندازه کافی کم است که در تولید برای بسیاری از برنامه ها قابل تحمل باشد
بدون مثبت کاذب
برای شناسایی خطاهای پشته به کد بازسازی نیاز ندارد (اما برای تشخیص خطاهای پشته نیاز دارد)
نیاز به ساخت کتابخانه های جداگانه برای هدف قرار دادن دستگاه های دارای MTE و غیر فعال کننده MTE دارد
ASan
ضدعفونی کننده آدرس که با نام ASan نیز شناخته می شود، قدیمی ترین و در دسترس ترین ابزار موجود است. برای تشخیص خطاهای حافظه در حین تست و اشکال زدایی که فقط دستگاه های قدیمی را تحت تأثیر قرار می دهد که هیچ یک از ابزارهای دیگر در دسترس نیستند، مفید است. در صورت امکان، HWASan را ترجیح دهید.
جوانب مثبت:
به طور گسترده در دسترس است. ممکن است روی دستگاه هایی به قدمت کیت کت کار کند
در صورت استفاده صحیح، هیچ مثبت یا منفی کاذب وجود ندارد
معایب:
ساخت و بسته بندی صحیح مشکل است
بالاترین سربار از همه گزینه ها: ~ 100٪ CPU، ~ 50٪ اندازه کد، ~ 100٪ استفاده از حافظه
دیگر پشتیبانی نمی شود
دارای اشکالات شناخته شده ای است که رفع نمی شود
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-08-13 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-13 بهوقت ساعت هماهنگ جهانی."],[],[],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"]]
