इस पेज का अनुवाद Cloud Translation API से किया गया है.

जेनेरिक कर्नेल इमेज (जीकेआई) रिलीज़ प्रोसेस

इस पेज पर बताया गया है कि जीकेआई कैसे रिलीज़ किया जाता है. इसमें हर हफ़्ते, हर महीने, और बिना बैंड के अचानक होने वाली रिलीज़ शामिल हैं. इस दस्तावेज़ का मकसद, OEM को GKI को कहां से लेने के बारे में दिशा-निर्देश देना है. साथ ही, इसमें आपातकालीन समस्याओं को ठीक करने के लिए, सामान्य प्रोसेस के अलावा अन्य तरीकों के बारे में भी बताया गया है. OEM, GKI के डेवलपमेंट का इस्तेमाल करके, इस बारे में ज़्यादा जान सकते हैं कि वे अपने प्रॉडक्ट के लिए GKI केनल को ऑप्टिमाइज़ करने के लिए, Android केनल टीम के साथ कैसे काम कर सकते हैं.

GKI रिलीज़ का केडेंस

केएमआई की पाबंदी के बाद, 'जीकेआई' को हर महीने के हिसाब से रिलीज़ किया जाता है.

Android 13, 14, और 15 GKI रिलीज़

नीचे दी गई टेबल सिर्फ़ android13-5.10, android13-5.15, और android14-5.15 पर लागू होती है.

GKI के हर महीने सर्टिफ़ाइड होने वाले बिल्ड	चेक-इन करने की आखिरी तारीख	GKI को प्रीलोड करने के लिए तैयार होने की तारीख	क्या आपने पुष्टि कर ली है?
नवंबर	11 नवंबर, 2024	27 नवंबर, 2024	हां
जनवरी	17 जनवरी, 2025	31 जनवरी, 2025	हां
मार्च	14 मार्च, 2025	31 मार्च, 2025	हां

नीचे दी गई टेबल सिर्फ़ android14-6.1 और android15-6.6 पर लागू होती है.

GKI के हर महीने सर्टिफ़ाइड होने वाले बिल्ड	चेक-इन करने की आखिरी तारीख	GKI को प्रीलोड करने के लिए तैयार होने की तारीख	पुष्टि की गई?
अक्टूबर	1 अक्टूबर, 2024	14 अक्टूबर, 2024	हां
नवंबर	1 नवंबर, 2024	15 नवंबर, 2024	हां
दिसंबर	2 दिसंबर, 2024	16 दिसंबर, 2024	हां
जनवरी	6 जनवरी, 2025	22 जनवरी, 2025	हां

Android 12 GKI रिलीज़

मई 2024 के बाद, android12-5.10 GKI की रिलीज़ तिमाही के हिसाब से होती हैं और इन्हें महीने के बीच में पब्लिश किया जाता है. यह टेबल सिर्फ़ android12-5.10 पर लागू होती है.

GKI के हर महीने सर्टिफ़ाइड होने वाले बिल्ड	चेक-इन करने की आखिरी तारीख	GKI को प्रीलोड करने के लिए तैयार होने की तारीख	क्या आपने पुष्टि कर ली है?
नवंबर	1 नवंबर, 2024	15 नवंबर, 2024	हां
फ़रवरी	3 फ़रवरी, 2025	17 फ़रवरी, 2025	हां

OEM के लिए GKI बिल्ड की समयसीमा

OEM, हाल ही में रिलीज़ किए गए Android GKI का इस्तेमाल कर सकते हैं. OEM, GKI से सर्टिफ़ाइड बिल्ड के साथ लॉन्च कर सकते हैं. हालांकि, इसके लिए ज़रूरी है कि वे Android Security Bulletin (ASB) में दी गई LTS की ज़रूरी शर्तों का पालन करते हों.

हर हफ़्ते रिलीज़ होने वाले डेवलपमेंट वर्शन

रिलीज़ की जांच Cuttlefish के साथ की जाती है, ताकि यह पक्का किया जा सके कि वे कम से कम क्वालिटी की शर्तें पूरी करती हैं.

बदलावों को मर्ज करने के बाद, GKI बाइनरी Android CI से सेल्फ़-सर्विस के लिए उपलब्ध हो जाती हैं. हर हफ़्ते के बिल्ड को सर्टिफ़ाइड नहीं किया जाएगा. हालांकि, इन्हें डेवलपमेंट और टेस्टिंग के लिए बेसलाइन के तौर पर इस्तेमाल किया जा सकता है. असली उपयोगकर्ताओं के लिए, हर हफ़्ते के बिल्ड का इस्तेमाल प्रोडक्शन डिवाइस बिल्ड के लिए नहीं किया जा सकता.

हर महीने सर्टिफ़ाइड रिलीज़

GKI की हर महीने की रिलीज़ में, टेस्ट किया गया boot.img शामिल होता है. इसमें Google का एक सर्टिफ़िकेट भी शामिल होता है. इससे यह पुष्टि होती है कि बाइनरी, किसी ऐसे सोर्स कोड बेसलाइन से बनाई गई हैं जिसकी जानकारी है.

हर महीने, चेक-इन की आखिरी तारीख के बाद, GKI के लिए हर महीने रिलीज़ होने वाले वर्शन (जिसे सर्टिफ़िकेट नहीं मिला है) को चुना जाता है. आम तौर पर, यह उस महीने का दूसरा हफ़्ते का बिल्ड होता है. महीने के हिसाब से रिलीज़ करने के लिए उम्मीदवार चुनने के बाद, उस महीने की रिलीज़ में नए बदलाव स्वीकार नहीं किए जाएंगे. क्लोज़्ड विंडो के दौरान, सिर्फ़ उन गड़बड़ियों को ठीक किया जा सकता है जिनकी वजह से टेस्ट पूरा नहीं हो पाता. रिलीज़ के लिए चुने गए वर्शन की क्वालिटी की पुष्टि की जाती है. इस बारे में जीकेआई की ज़रूरी शर्तों वाले सेक्शन में बताया गया है. इससे यह पक्का किया जाता है कि जीएसआई और जीकेआई के बने वर्शन, रेफ़रंस डिवाइस और कटलफ़िश के साथ कंप्लायंस टेस्ट पास कर पाएं.

पहली इमेज. GKI रिलीज़ की टाइमलाइन

आपातकालीन स्थिति में फिर से अनुरोध करने की प्रोसेस

रेस्पिन का मतलब है, जीकेआई कर्नेल के सार्वजनिक रिलीज़ के बाद, बाइनरी को फिर से मर्ज करने, बनाने, उसकी दोबारा जांच करने, और उसे दोबारा प्रमाणित करने की प्रोसेस. सर्टिफ़ाइड बाइनरी को फिर से सबमिट करने का अनुरोध, इनमें से किसी भी स्थिति में किया जा सकता है:

सिंबल की सूची अपडेट करने के लिए.
किसी गड़बड़ी को ठीक करने के लिए. इसमें, कैरियर लैब से अनुमति मिलने के दौरान मिली गड़बड़ियां भी शामिल हैं.
वेंडर हुक जोड़ने के लिए.
किसी मौजूदा सुविधा में पैच लागू करने के लिए.
सुरक्षा पैच लागू करने के लिए (छह महीने बाद).

सुरक्षा पैच, रिलीज़ शाखा के रिलीज़ होने के बाद, छह महीने तक रिलीज़ शाखा में अपने-आप मर्ज हो जाते हैं. छह महीने के बाद, आपको किसी शाखा में सुरक्षा पैच लागू करने के लिए, फिर से अनुरोध करना होगा.

ट्रांसफ़र करने के अनुरोध से जुड़े दिशा-निर्देश

फिर से अनुरोध करने का अनुरोध करने से पहले, इन दिशा-निर्देशों को ध्यान में रखें:

किसी महीने के बिल्ड के शुरुआती सार्वजनिक रिलीज़ के लॉन्च होने के बाद ही, रिलीज़ ब्रांच पर रीपिन की अनुमति है.
किसी रिलीज़ शाखा के लिए, फिर से स्पिन करने के अनुरोध सिर्फ़ शुरुआती सार्वजनिक रिलीज़ के बाद, ज़्यादा से ज़्यादा छह महीने तक स्वीकार किए जाते हैं. छह महीने के बाद, सिर्फ़ Android Security Bulletin में बताए गए सुरक्षा पैच के लिए, शाखाओं को फिर से सबमिट करने की अनुमति मिलती है.
जब Android सिक्योरिटी बुलेटिन (एएसबी) में बताई गई एलटीएस की ज़रूरी शर्तों की वजह से ब्रांच, इन शर्तों का पालन नहीं करती है, तो ब्रांच को हटा दिया जाता है. बंद की गई शाखाओं के लिए, फिर से स्पिन करने के अनुरोध स्वीकार नहीं किए जाते. किसी GKI रिलीज़ ब्रैंच के बंद होने की तारीख, हर महीने के GKI रिलीज़ बिल्ड नोट में शामिल होती है. यह नोट, रिलीज़ में दिखता है. आने वाले समय में प्लान बनाने के लिए, LTS की ज़रूरी शर्तों को हर साल मई और नवंबर में अपडेट किया जाता है. उदाहरण के लिए, android12-5.10-2023-07 की ब्रांच (5.10.177) को 1 मई, 2024 के बाद, रिस्पॉन्स के तौर पर फिर से इस्तेमाल नहीं किया जा सकेगा. इसकी वजह यह है कि android12-5.10-2023-07 ब्रांच (5.10.177) ASB-2024-05 की एलटीएस (लंबे समय तक सहायता) की शर्तों का पालन नहीं करती.
रीस्पिन सिर्फ़ गड़बड़ी को तुरंत ठीक करने, सिंबल की सूची में अपडेट करने या किसी मौजूदा सुविधा को ठीक करने के लिए पैच लागू करने के लिए लागू होते हैं.
हर महीने रिलीज़ होने वाली शाखा में शामिल होने वाले सभी पैच, GKI की मुख्य डेवलपमेंट शाखा में पहले से ही मर्ज होने चाहिए. उदाहरण के लिए, अगर android12-5.10-2022-09 को फिर से स्पिन करने के लिए पैच की ज़रूरत है, तो उसे पहले से ही android12-5.10 में मर्ज किया जाना चाहिए.
आपको GKI की मुख्य डेवलपमेंट शाखा से पैच चुनने होंगे और उन पैच को हर महीने रिलीज़ होने वाली शाखा पर अपलोड करना होगा.

अनुरोध को फिर से सबमिट करने के लिए, आपको अनुरोध को प्राथमिकता (ज़रूरत) असाइन करनी होगी. इस प्राथमिकता से GKI टीम को, समय पर पार्टनर की बेहतर मदद करने में मदद मिलती है. ज़रूरी या समय के हिसाब से संवेदनशील अनुरोधों के लिए, प्राथमिकता को P0 के तौर पर मार्क करें. P0 और P1 अनुरोधों के लिए, आपको यह भी बताना होगा कि बहुत कम समय के लिए वाकई ऐसा करना क्यों ज़रूरी है. नीचे दी गई टेबल में, गड़बड़ी की प्राथमिकता और उसे ठीक करने में लगने वाले समय (ईएसआरटी) को मैप किया गया है:

प्राथमिकता	ESRT
P0	2 व्यावसायिक दिन
P1	5 कामकाजी दिन
P2	10 कामकाजी दिन
P3	15 कार्यदिवस

आपको हर रिलीज़ शाखा के लिए, फिर से सबमिट करने का अलग अनुरोध सबमिट करना होगा. उदाहरण के लिए, अगर android12-5.10-2022-08 और android12-5.10-2022-09, दोनों के लिए रीस्पिन की ज़रूरत है, तो आपको दो रीस्पिन अनुरोध करने होंगे.
कोई बिल्ड उपलब्ध कराने और फिर से समीक्षा का अनुरोध 'ठीक हो गया' के तौर पर मार्क होने के बाद, आपको और सीएल जोड़ने के लिए, फिर से समीक्षा का अनुरोध नहीं करना चाहिए. अगर ऐसे और पैच हैं जिन्हें मर्ज करना है, तो आपको फिर से अनुरोध सबमिट करना होगा.
जिन सीएल पर विचार किया जा रहा है उनके लिए, ये टैग जोड़ें.
- Bug: हर सीएल के लिए, बग आईडी को कमिट मैसेज में जोड़ना ज़रूरी है.
- Change-Id: यह बदलाव की बुनियादी शाखा के Change-Id से मेल खाना चाहिए.
ध्यान दें: इन टैग के बिना, फिर से अनुरोध करने की प्रोसेस को ब्लॉक कर दिया जाता है.
अगर किसी अनुरोध को फिर से भेजने के लिए आपका जवाब ज़रूरी है और आप तीन कामकाजी दिनों के अंदर जवाब नहीं देते, तो प्राथमिकता को एक लेवल कम कर दिया जाता है. उदाहरण के लिए, P0 को P1 पर लेवल कम कर दिया जाता है. अगर दो हफ़्तों तक कोई जवाब नहीं मिलता है, तो गड़बड़ी को ठीक नहीं किया जाएगा (अमान्य) के तौर पर मार्क कर दिया जाता है.

फिर से अनुरोध सबमिट करना

इस डायग्राम में, फिर से अनुरोध करने की प्रोसेस दिखाई गई है. यह प्रोसेस तब शुरू होती है, जब OEM पार्टनर (आप) फिर से अनुरोध सबमिट करता है.

आपातकालीन स्थिति में फिर से अनुरोध करने की प्रोसेस दूसरी इमेज. रेसिन प्रोसेस

फिर से अनुरोध करने की प्रोसेस शुरू करने के लिए:

GKI के लिए फिर से अनुरोध करने का फ़ॉर्म भरें. इसके बाद, अपने Google तकनीकी खाता मैनेजर से तुरंत संपर्क करें. इस फ़ॉर्म से, GKI के अनुरोध को अस्वीकार करने से जुड़ी गड़बड़ी पैदा होती है. अनुरोध के रिस्पॉन्स से जुड़ी गड़बड़ियां, आपको (अनुरोध करने वाले व्यक्ति), जीकेआई टीम, और उन लोगों को दिखती हैं जिन्हें आपने गड़बड़ी की कॉपी सूची में जोड़ा है.
- अगर आपने पहले ही गड़बड़ी को ठीक कर लिया है, तो अनुरोध में AOSP में सबमिट किए गए पैच के बारे में बताया जाना चाहिए, ताकि Google उसकी समीक्षा कर सके. अगर पैच सबमिट करना संभव नहीं है, तो पैच को अनुरोध में टेक्स्ट फ़ाइल के तौर पर अटैच करना होगा.
- अगर आपके पास समस्या को ठीक करने का तरीका नहीं है, तो अनुरोध में ज़्यादा से ज़्यादा जानकारी होनी चाहिए. इसमें, कर्नेल वर्शन नंबर और लॉग शामिल होने चाहिए, ताकि Google समस्या को डीबग करने में आपकी मदद कर सके.
Google GKI टीम अनुरोध की समीक्षा करती है और उसे मंज़ूरी देती है. इसके अलावा, ज़्यादा जानकारी की ज़रूरत होने पर, वह आपको वापस असाइन करती है.
समस्या को ठीक करने के लिए सहमति मिलने के बाद, Google GKI टीम कोड की समीक्षा करती है (CR+2). समीक्षा, ईएसआरटी समयसीमा से शुरू होती है. जीकेआई टीम बदलाव को मर्ज करती है, बनाती है, रिग्रेशन की जांच करती है, और बदलाव को प्रमाणित करती है.
बाइनरी को ci.android.com पर रिलीज़ किया जाता है. इसके बाद, ईएसआरटी की समयसीमा खत्म हो जाती है और Google GKI टीम, अनुरोध को ठीक के तौर पर मार्क कर देती है. साथ ही, फिर से भेजे गए बिल्ड का रेफ़रंस देती है. फिर से भेजा गया बिल्ड, Generic Kernel Image (GKI) रिलीज़ बिल्ड पेज पर भी पोस्ट किया जाएगा.

GKE (जीकेआई) से जुड़ी योग्यताएं

GKI के अलग-अलग तरह के बिल्ड	क्वालिटी को बेहतर बनाने का तरीका	Notes
हर हफ़्ते	कटलफ़िश टेस्टिंग बूट VTS का सबसेट सीटीएस का सबसेट	सर्टिफ़िकेट नहीं है. सिर्फ़ टेस्टिंग के लिए और डिवाइस को फ़ेच किया जाता है. डिवाइसों को लॉन्च करने के लिए इसका इस्तेमाल नहीं किया जा सकता.
हर महीने (सर्टिफ़ाइड)	कटलफ़िश टेस्टिंग बूट VTS सीटीएस हार्डवेयर की जांच से जुड़े रेफ़रंस बूट VTS सीटीएस
रीस्पिन (सर्टिफ़ाइड)	कटलफ़िश टेस्टिंग बूट VTS सीटीएस का सबसेट डिवाइस की जांच के लिए रेफ़रंस बूट VTS	इसे GKI (जीकेआई) प्रमाणित बिल्ड के आधार पर बनाया गया है. ज़रूरी शर्तें पूरी करने के बाद, बिल्ड को सर्टिफ़िकेट मिलता है.

GKI के अलग-अलग तरह के बिल्ड

क्वालिटी को बेहतर बनाने का तरीका

Notes

हर हफ़्ते

कटलफ़िश टेस्टिंग

बूट
VTS का सबसेट
सीटीएस का सबसेट

सर्टिफ़िकेट नहीं है. सिर्फ़ टेस्टिंग के लिए और
डिवाइस को फ़ेच किया जाता है.
डिवाइसों को लॉन्च करने के लिए इसका इस्तेमाल नहीं किया जा सकता.

हर महीने (सर्टिफ़ाइड)

कटलफ़िश टेस्टिंग

बूट
VTS
सीटीएस

हार्डवेयर की जांच से जुड़े रेफ़रंस

बूट
VTS
सीटीएस

रीस्पिन (सर्टिफ़ाइड)

कटलफ़िश टेस्टिंग

बूट
VTS
सीटीएस का सबसेट

डिवाइस की जांच के लिए रेफ़रंस

बूट
VTS

इसे GKI (जीकेआई) प्रमाणित बिल्ड के आधार पर बनाया गया है.
ज़रूरी शर्तें पूरी करने के बाद, बिल्ड को सर्टिफ़िकेट मिलता है.

बिल्ड आर्टफ़ैक्ट कहां से पाएं

सभी रिलीज़ के आर्टफ़ैक्ट, ci.android.com से पाए जा सकते हैं.

सीआई के बारे में ज़्यादा जानकारी पाने के लिए, Android के लिए सीआई डैशबोर्ड पर जाएं. यहां आपको टेस्ट के नतीजे भी दिखेंगे.

अक्सर पूछे जाने वाले सवाल

यहां GKI रिलीज़ की प्रोसेस के बारे में अक्सर पूछे जाने वाले कुछ सवाल दिए गए हैं.

क्या पहले से रिलीज़ हो चुके जीकेआई के आधार पर नई जीकेआई बाइनरी बनाना मुमकिन है?

हां, इसे फिर से अनुरोध करना कहते हैं. फिर से सबमिट करने की प्रोसेस तब तक काम करती है, जब तक कि रिलीज़ किया गया GKI बिल्ड (जिस पर फिर से सबमिट करने का अनुरोध किया गया है) Android Security Bulletin (ASB) में दी गई LTS की ज़रूरी शर्तों के मुताबिक हो.

क्या GKI बाइनरी को फिर से बनाया जा सकता है?

हां, यहां एक उदाहरण दिया गया है:

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

उदाहरण को फिर से चलाने के लिए, manifest_$id.xml डाउनलोड करें और यह कमांड चलाएं:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

out/.../dist से अपने GKI आर्टफ़ैक्ट की कॉपी वापस पाई जा सकती है.

क्या जीकेआई बाइनरी (इसमें इमरजेंसी स्पिन पैच भी शामिल है) सबसे नए कोड बेस पर बनाया गया है?

नहीं. रीस्पिन में सिर्फ़ वे पैच शामिल होते हैं जो हर महीने सर्टिफ़ाइड किए गए, चुने गए मुख्य कर्नेल के ऊपर होते हैं. इन respins में, लॉन्च को रोकने वाली सभी गड़बड़ियों को ठीक करने के लिए, OEMs ने जो बदलाव किए हैं वे शामिल होते हैं. ये बदलाव, हर महीने की रिलीज़ के हिसाब से किए जाते हैं. इस तरह की स्थिति कैसे होती है, इसका उदाहरण यहां देखें.

OEM1 और OEM2 ने नवंबर 2021 से, GKI बाइनरी रिलीज़ का इस्तेमाल करने का फ़ैसला किया है.
OEM1 और OEM2 को ऐसी समस्याएं मिलती हैं जिनके लिए सहायता पाने के लिए पैच की ज़रूरत होती है. ये पैच एक जैसे या अलग-अलग हो सकते हैं.
नवंबर 2021 के बाइनरी के ऊपर मौजूद रीस्पिन में, लॉन्च को ब्लॉक करने से जुड़ी समस्याओं को ठीक करने के लिए, रीस्पिन विंडो के दौरान OEM1 और OEM2, दोनों ने सुधार किए हैं. हालांकि, इसमें और कुछ नहीं है.
दूसरे बुलेट में बताई गई समस्याओं को, GKI की हर महीने होने वाली रिलीज़ में भी शामिल किया जाता है.

अक्टूबर के रिस्पॉन में, OEM के सबमिट किए गए सभी पैच शामिल हैं. हालांकि, OEM के अन्य पैच का असर हम पर पड़ता है, क्योंकि इनकी जांच खास तौर पर हमारे प्रॉडक्ट के साथ नहीं की गई है. क्या सिर्फ़ हमारा पैच शामिल किया जा सकता है?

ऐसा नहीं किया जा सकता. "हर OEM के लिए" respin पाथ को स्केल नहीं किया जा सकता. इसके बजाय, GKI टीम, रिस्पॉन्सिव बिल्ड में किए गए हर बदलाव की जांच करती है. साथ ही, नया बिल्ड बनाने से पहले, सभी उपलब्ध हार्डवेयर के साथ बदलावों की जांच करती है. अगर GKI टीम को पता चलता है कि समस्या किसी OEM, डिवाइस या मॉडल से जुड़ी है, तो GKI टीम यह पक्का कर सकती है कि बदलाव से जोड़ा गया कोड सिर्फ़ उस डिवाइस, मॉडल या SKU पर लागू हो जिस पर असर पड़ा है.

एक जैसे रिस्पॉन्स का सबसे बड़ा फ़ायदा यह है कि एक ही रिलीज़ बेस का इस्तेमाल करने वाले हर डिवाइस को एक-दूसरे से फ़ायदा मिलता है. खास तौर पर, अगर उन डिवाइसों में सामान्य और सभी उपयोगकर्ताओं पर लागू होने वाले बग मिलते हैं. कैरियर टेस्टिंग में मिले मुख्य कर्नेल बग, इस कॉन्सेप्ट का एक खास उदाहरण हैं.

क्या कोई ऐसी स्थिति है जिसमें Google, OEM पैच और समस्या की स्थितियों के बारे में खास जानकारी देता है, ताकि OEM अपने प्रॉडक्ट के साथ पैच इस्तेमाल करने के असर और जोखिम का आकलन कर सकें?

Google, जब तक समस्या को समझ नहीं लेता और पूरी जानकारी इकट्ठा नहीं कर लेता, तब तक फिर से सबमिट किए गए बिल्ड में कोई बदलाव नहीं करेगा. यह बदलाव, बदलावों की सूची (कमिट मैसेज) में दिखता है. Google यह नहीं बताता कि किस डिवाइस पर इसका असर पड़ेगा. हालांकि, OEMs को बदलाव लॉग में समस्या की जानकारी और समाधान हमेशा मिल सकता है.