C और C++ में मेमोरी को शुरू न करने की वजह से, भरोसे से जुड़ी समस्याएं, मेमोरी की सुरक्षा से जुड़े गड़बड़ियां, और जानकारी लीक होने की समस्याएं आम तौर पर होती हैं. इन समस्याओं से बचने के लिए, Android ज़्यादा से ज़्यादा मेमोरी को शुरू करता है.
यूज़रस्पेस मेमोरी को शून्य पर शुरू किया गया
Android 12 के बाद, सभी प्लैटफ़ॉर्म के नेटिव कोड (इसमें JNI भी शामिल है) में स्टैक मेमोरी को शून्य से शुरू किया जाता है. साथ ही, सभी प्लैटफ़ॉर्म की नेटिव प्रोसेस (जैसे, netd) में हीप मेमोरी को शून्य से शुरू किया जाता है, न कि zygote या ऐप्लिकेशन में.
NDK का इस्तेमाल करके बनाए गए पहले और तीसरे पक्ष के ऐप्लिकेशन के लिए, -ftrivial-auto-var-init=zero कंपाइलर फ़्लैग का इस्तेमाल करने का सुझाव दिया जाता है. इससे, स्टैक के लोकल वैरिएबल को शून्य से शुरू किया जा सकता है. कंपाइलर, ग़ैर-ज़रूरी शून्य को ऑप्टिमाइज़ कर देता है.
उदाहरण के लिए, जब किसी स्थानीय वैरिएबल को साफ़ तौर पर शुरू किया जाता है (जैसे, int x = 123; वैरिएबल x को सिर्फ़ एक बार शुरू किया जाता है).
अगर प्रोग्राम में परफ़ॉर्मेंस के हॉटस्पॉट में बड़ा स्टैक बफ़र है, तो डेवलपर कंपाइलर एट्रिब्यूट का इस्तेमाल करके, शुरू करने की प्रोसेस को बंद कर सकता है:
__attribute__((__uninitialized__)) char buf[BUFSIZ];
ऐप्लिकेशन, android:nativeHeapZeroInitialized मेनिफ़ेस्ट एट्रिब्यूट का इस्तेमाल करके, हेप को शून्य से शुरू करने की सुविधा के लिए भी ऑप्ट इन कर सकते हैं.
इसके अलावा, रनटाइम पर ढेर के शून्य को इनके साथ शुरू किया जा सकता है:
int mallopt(M_BIONIC_ZERO_INIT, level)
जहां लेवल 0 या 1 है.
शून्य से शुरू की गई कर्नेल मेमोरी
GKI कर्नेल के लिए, कर्नेल स्टैक और हेप को शून्य से शुरू किया जाता है. सीडीडी का सुझाव है कि ऐसा करना ज़रूरी है.
स्टैक को शुरू करने के लिए, GKI,
CONFIG_INIT_STACK_ALL_ZERO कॉन्फ़िगरेशन का इस्तेमाल करता है. इससे, -ftrivial-auto-var-init=zero कंपाइलर फ़्लैग का इस्तेमाल करके,
कर्नेल बनता है.
ढेर को शुरू करने के लिए, GKI CONFIG_INIT_ON_ALLOC_DEFAULT_ON का इस्तेमाल करता है. इससे, सभी पेज ढेर, स्लैब, और स्लूब को बनाने के दौरान शून्य से शुरू किया जाता है. यह विकल्प, init_on_alloc=1 को बूट-टाइम विकल्प के तौर पर पास करने के बराबर है.
गड़बड़ी की रिपोर्ट
हमारे टूल, गड़बड़ी की अहम जानकारी देने वाली रिपोर्ट जनरेट करते हैं. इनमें डीबग करने में मदद करने के लिए, ज़्यादा जानकारी होती है. अतिरिक्त ऐलोकेशन और डिऐलोकेशन स्टैक ट्रेस की मदद से, किसी ऐलोकेशन के लाइफ़साइकल को बेहतर तरीके से समझा जा सकता है. साथ ही, इससे मेमोरी से जुड़ी सुरक्षा से जुड़ी गड़बड़ियों की वजहों का पता बहुत तेज़ी से चलता है.
डेवलपमेंट के दौरान, वेंडर को नेटिव क्रैश की जांच करके, बग की मौजूदगी पर नज़र रखनी चाहिए. इसके लिए,
/data/tombstones और
logcat को देखें. Android नेटिव कोड को डिबग करने के बारे में ज़्यादा जानकारी के लिए, यहां देखें.