Android는 메모리 오류 디버깅을 위한 여러 도구를 지원합니다. 도구별로 장단점이 있으니 아래 내용을 참고하여 사용 사례에 가장 적합한 방법을 결정하세요. 이 문서에서는 더 자세히 살펴볼 수 있도록 각 도구를 간략하게 설명합니다. 설명이 자세하지 않으니 자세한 내용은 각 도구의 문서를 참고하세요.
메모리 안전 언어는 메모리 오류를 완전히 방지하고 완화할 수 있는 유일한 방법입니다. 이 페이지에서 설명하는 다른 도구를 사용하면 메모리에 안전하지 않은 코드를 더 안전하고 안정적으로 만드는 데 도움이 될 수 있으나, 메모리 안전 언어를 사용하면 모든 유형의 문제가 사라집니다.
Android에서 공식적으로 지원되는 메모리 안전 언어는 Java와 Kotlin입니다.
대부분의 Android 애플리케이션은 이러한 언어 중 하나로 개발하는 것이 쉽습니다.
그러나 시중에는 Rust로 작성된 코드를 제공하는 앱 개발자가 있으며, 이 페이지를 보고 있다는 것은 네이티브 코드가 필요한 이유가 있기 때문일 것입니다(이동성, 성능 또는 둘 다). Rust는 Android의 메모리 안전 네이티브 코드에 가장 적합합니다. 이 방법을 사용할 경우 NDK팀에서 문제 해결을 지원하지 못할 수 있지만, 저희에게 알려주시면 도움이 됩니다.
PAC/BTI
포인터 인증 및 브랜치 타겟 식별(PAC/BTI)은 프로덕션에서 사용하기에 적합한 완화 도구입니다.
이 두 가지는 서로 다른 기술이긴 하나, 동일한 컴파일러 플래그로 제어되므로 항상 함께 사용됩니다.
이러한 기능은 이를 지원하지 않는 기기와 하위 호환됩니다. 이전 기기에서 사용된 새 명령이 노옵스(no-ops)이기 때문입니다. 또한 최신 커널과 최신 버전의 OS가 있어야 합니다.
/proc/cpuinfo에서 paca 및 bti를 찾으면 최신 하드웨어와 최신 커널이 있는지 알 수 있습니다. Android 12(API 31)에는 필요한 사용자 공간이 지원됩니다.
장점:
이전 기기나 커널에서 문제를 일으키지 않고 모든 빌드에서 사용 설정할 수 있습니다. 하지만 이를 지원하는 기기/커널/OS 조합에서 실제로 테스트했는지 확인하세요.
단점:
64비트 앱에서만 사용할 수 있습니다.
지원하지 않는 기기의 오류는 완화하지 않습니다.
코드 크기의 1%에 해당하는 오버헤드가 발생합니다.
GWP-Asan
GWP-ASan은 필드에서 메모리 오류를 감지하는 데 사용할 수 있으나, 샘플링 레이트가 너무 낮아서 효과적인 완화가 어렵습니다.
장점:
큰 CPU 또는 메모리 오버헤드가 없습니다.
간편한 배포: 네이티브 코드를 다시 빌드할 필요가 없습니다.
32비트 앱에서 작동합니다.
단점:
샘플링 레이트가 낮은 경우 버그를 효과적으로 찾으려면 많은 사용자가 필요합니다.
힙 오류만 감지하고 스택 오류는 감지하지 않습니다.
HWASan
Hardware Address Sanitizer(HWASan)는 테스트 중에 메모리 오류를 포착하는 데 가장 적합합니다. 자동 테스트와 함께 사용할 때, 특히 퍼징 테스트를 실행하는 경우에 가장 유용하지만, 앱의 성능에 따라 dogfood 설정의 고급형 휴대전화에서도 사용할 수 있습니다.
장점:
거짓양성이 없습니다.
ASan이 감지하지 못하는 추가적인 유형의 오류를 감지합니다(반환 후 스택 사용).
MTE보다 거짓음성률이 낮습니다(HWASan: 256개 중 1개, MTE: 16개 중 1개).
MTE 지원 기기와 비 MTE 지원 기기를 모두 타겟팅하려면 별도의 라이브러리를 빌드해야 합니다.
ASan
Address Sanitizer(ASan)는 사용 가능한 도구 중에서 가장 오래되고 가장 널리 사용되는 도구입니다. 다른 도구를 사용할 수 없는, 이전 기기에만 영향을 주는 문제를 테스트 및 디버깅할 때 메모리 오류를 포착하는 데 유용합니다. 가능한 경우 항상 HWASan을 사용하세요.
장점:
널리 사용됩니다. KitKat과 같은 이전 기기에서 작동할 수 있습니다.
올바르게 사용할 경우 거짓양성이나 거짓음성이 없습니다.
단점:
올바르게 빌드하고 패키징하기가 어렵습니다.
CPU ~100%, 코드 크기 ~50%, 메모리 사용량 ~100% 등 모든 옵션 중에서 오버헤드가 가장 큽니다.
더 이상 지원되지 않습니다.
앞으로 수정되지 않을 알려진 버그가 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-08-21(UTC)
[[["이해하기 쉬움","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(UTC)"],[],[],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"]]
