शून्य इनिशलाइज़्ड मेमोरी

C और C++ में शुरू न होने वाली मेमोरी, विश्वसनीयता से जुड़ी समस्याओं की एक आम वजह है. मेमोरी की सुरक्षा से जुड़ी गड़बड़ियां और जानकारी लीक हो सकती है. इन समस्याओं से बचने के लिए, Android पर जितनी हो सके उतनी मेमोरी शुरू करता है.

शुरू की गई यूज़रस्पेस मेमोरी

Android 12 और इसके बाद के वर्शन में, स्टैक मेमोरी शून्य है सभी प्लैटफ़ॉर्म के नेटिव कोड (JNI सहित) में और हीप मेमोरी शून्य है सभी प्लैटफ़ॉर्म के नेटिव प्रोसेस (जैसे कि netd) में शुरू की गई हालाँकि, zygote या ऐप्लिकेशन में नहीं.

एनडीके (NDK) के साथ बनाए गए पहले और तीसरे पक्ष के ऐप्लिकेशन, अपने स्टैक लोकल में शून्य से शुरू करने के लिए, -ftrivial-auto-var-init=zero कंपाइलर फ़्लैग का इस्तेमाल करने का सुझाव दिया जाता है वैरिएबल. कंपाइलर गै़र-ज़रूरी किसी भी ज़ीरो को ऑप्टिमाइज़ कर देता है. उदाहरण के लिए, जब कोई लोकल वैरिएबल साफ़ तौर पर शुरू किया जाता है (जैसे, int x = 123; वैरिएबल x सिर्फ़ एक बार शुरू किया जाता है). अगर प्रोग्राम की परफ़ॉर्मेंस में बड़ा स्टैक बफ़र है हॉटस्पॉट, तो डेवलपर कंपाइलर का इस्तेमाल करके शुरू करने की प्रोसेस बंद कर सकता है विशेषता:

__attribute__((__uninitialized__)) char buf[BUFSIZ];

ऐप्लिकेशन, Android 14 में मिलने वाली हीप ज़ीरो इनिशलाइज़ेशन android:nativeHeapZeroInitialized मेनिफ़ेस्ट एट्रिब्यूट. इसके अलावा, रनटाइम के दौरान हीप ज़ीरो इनिशलाइज़ेशन को कंट्रोल किया जा सकता है इनके साथ:

int mallopt(M_BIONIC_ZERO_INIT, level)

जहां लेवल 0 या 1 होता है.

शून्य इनिशलाइज़्ड कर्नेल मेमोरी

जीकेआई कर्नेल के लिए, कर्नेल स्टैक और हीप शून्य शुरू किए गए हैं, जो कि पूरी तरह से का सुझाव दिया जाता है.

स्टैक शुरू करने के लिए, जीकेआई CONFIG_INIT_STACK_ALL_ZERO कॉन्फ़िगरेशन जिससे यह बनती है कर्नेल का इस्तेमाल करके, -ftrivial-auto-var-init=zero कंपाइलर फ़्लैग का इस्तेमाल करता है. हीप शुरू करने के लिए, जीकेआई CONFIG_INIT_ON_ALLOC_DEFAULT_ON, जिससे पूरा पेज हीप होता है, SLAB और एसएलयूबी ऐलोकेशन शून्य शुरू हो जाता है और वे बनाए जाते हैं. यह विकल्प है असरदार तरीके से, init_on_alloc=1 को कर्नेल के तौर पर पास करने के बराबर है बूट-टाइम विकल्प.

गड़बड़ी की रिपोर्ट

हमारे टूल, गड़बड़ी की ऐसी अहम रिपोर्ट जनरेट करते हैं जिनमें ज़्यादा जानकारी होती है डीबग करने में मदद करने के लिए. अतिरिक्त ऐलोकेशन और डीललोकेशन स्टैक ट्रेस असाइन किए गए बजट की लाइफ़ साइकल को बेहतर ढंग से समझने में मदद मिलती है. जिससे मेमोरी की सुरक्षा में आने वाली गड़बड़ियां बहुत तेज़ी से पैदा होती हैं.

डेवलपमेंट के दौरान, वेंडर को जांच करके गड़बड़ियों की मौजूदगी पर नज़र रखनी चाहिए /data/tombstones और नेटिव क्रैश के लिए logcat. अगर आपको ज़्यादा जानकारी चाहिए, तो Android नेटिव कोड को डीबग करने से जुड़ी जानकारी यहां देखें.