از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
حافظه اولیه در C و C++ یکی از دلایل رایج مشکلات قابلیت اطمینان، اشکالات ایمنی حافظه و نشت اطلاعات است. برای جلوگیری از این مشکلات، اندروید تا حد ممکن حافظه را مقداردهی اولیه می کند.
حافظه فضای کاربری اولیه صفر
از اندروید 12، حافظه پشته در تمام کدهای بومی پلتفرم (از جمله JNI) صفر است و حافظه پشته در تمام فرآیندهای بومی پلتفرم (مانند netd ) صفر است، اما در zygote یا در برنامه‌ها صفر است.
برنامه های شخص اول و شخص ثالث ساخته شده با NDK اکیداً توصیه می شود از پرچم کامپایلر-ftrivial-auto-var-init=zero برای صفر کردن متغیرهای محلی پشته خود استفاده کنند. کامپایلر هرگونه صفر کردن غیر ضروری را بهینه می کند. به عنوان مثال، زمانی که یک متغیر محلی به طور صریح مقداردهی اولیه می شود (مانند، int x = 123; متغیر x تنها یک بار مقداردهی اولیه می شود). اگر برنامه دارای یک بافر پشته بزرگ در یک نقطه عملکردی باشد، توسعه دهنده می تواند با استفاده از یک ویژگی کامپایلر، مقداردهی اولیه را غیرفعال کند:
برنامه‌ها همچنین می‌توانند با استفاده از ویژگی مانیفست android:nativeHeapZeroInitialized مقداردهی اولیه صفر را انتخاب کنند. از طرف دیگر، مقدار دهی اولیه Heap Zero را می توان در زمان اجرا با موارد زیر کنترل کرد:
برای مقداردهی اولیه پشته، GKI از پیکربندی CONFIG_INIT_STACK_ALL_ZERO استفاده می کند که منجر به ساخت هسته با استفاده از پرچم کامپایلر -ftrivial-auto-var-init=zero . برای مقداردهی اولیه پشته، GKI از CONFIG_INIT_ON_ALLOC_DEFAULT_ON استفاده می‌کند، که باعث می‌شود تمام تخصیص‌های صفحه پشته، SLAB و SLUB هنگام ایجاد، صفر اولیه شوند. این گزینه به طور موثر شبیه به ارسال init_on_alloc=1 به عنوان گزینه بوت زمان هسته است.
گزارش اشکال
ابزارهای ما گزارش‌های باگ روشن‌گری را تولید می‌کنند که حاوی اطلاعات اضافی برای کمک به اشکال‌زدایی است. تخصیص اضافی و ردیابی پشته توزیع به درک بهتر چرخه عمر یک تخصیص داده شده کمک می کند و منجر به ایجاد اشکالات ایمنی حافظه بسیار سریعتر می شود.
شکل 1 : گزارش های اشکال تولید شده توسط ابزار ایمنی حافظه
در طول توسعه، فروشندگان باید با بررسی /data/tombstones و logcat برای خرابی های بومی، وجود اشکالات را کنترل کنند. برای اطلاعات بیشتر در مورد اشکال زدایی کد بومی اندروید، اطلاعات اینجا را ببینید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Zero initialized memory\n\nUninitialized memory in C and C++ is a common cause of reliability problems,\nmemory safety bugs and information leaks. To avoid these issues, Android\ninitializes as much memory as possible.\n\nZero initialized userspace memory\n---------------------------------\n\n\nSince Android 12, stack memory is zero initialized\nin all platform native code (including JNI) and heap memory is zero\ninitialized in all platform native processes (such as `netd`)\nbut not in the `zygote` or in apps.\n\n\nFirst and third-party apps built with the NDK are strongly\nrecommended to use the `-ftrivial-auto-var-init=zero` [compiler flag](https://cs.android.com/android/platform/superproject/+/android-latest-release:build/soong/cc/config/global.go;l=183;drc=bd20ccb83ef87bba9fdf31a937ccb7b921d67b73) to zero-initialize their stack local\nvariables. The compiler optimizes away any zeroing that is unnecessary.\nFor example, when a local variable is explicitly initialized\n(such as, `int x = 123;` variable `x` is initialized only once).\nIf the program has a large stack buffer in a performance\nhotspot, the developer can disable initialization using a compiler\nattribute:\n`\n__attribute__((__uninitialized__)) char buf[BUFSIZ];\n`\n\n\nApps can also opt in to heap zero initialization by using the\n`android:nativeHeapZeroInitialized` manifest attribute.\nAlternatively, heap zero initialization can be controlled at runtime\nwith:\n`\nint mallopt(M_BIONIC_ZERO_INIT, level)\n`\n\n\nWhere level is 0 or 1.\n| **Note:** Arm MTE implicitly zero-initializes almost all heap memory, with the exception of a small number of large heap allocations. We encourage C/C++ developers to use zero initialized memory wherever possible.\n\nZero initialized kernel memory\n------------------------------\n\n\nThe kernel stack and heap is zero initialized for GKI kernels, which is [strongly\nrecommended by the CDD](/docs/compatibility/13/android-13-cdd#97_security_features).\n\n\nFor stack initialization, GKI uses the\n`CONFIG_INIT_STACK_ALL_ZERO` config, which results in building the\nkernel using the `-ftrivial-auto-var-init=zero` compiler flag.\nFor heap initialization, GKI uses the\n`CONFIG_INIT_ON_ALLOC_DEFAULT_ON`, which makes all page heap, SLAB\nand SLUB allocations zero-initialized when they are created. This option is\neffectively similar to passing `init_on_alloc=1` as a kernel\nboot-time option.\n\nBug reports\n-----------\n\n\nOur tools generate insightful bug reports that contain additional information\nto aid with debugging. The additional allocation and deallocation stack trace\nhelp better understand the life cycle of a given allocation and lead to\nroot-causing memory safety bugs much faster.\n**Figure 1**: Bug reports generated by memory safety tools\n\n\nDuring development, vendors should monitor the presence of bugs by checking\n`/data/tombstones` and\n`logcat` for native crashes. For more information on\ndebugging Android native code see the information [here](/devices/tech/debug)."]]
