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

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

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

केएमआई फ़्रीज़ होने के बाद, जीकेआई को हर महीने रिलीज़ किया जाता है.

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

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

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

Android 12 GKI रिलीज़

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

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

OEM, हाल ही में रिलीज़ किए गए Android GKI का इस्तेमाल कर सकते हैं. ओईएम, जीकेआई से प्रमाणित बिल्ड के साथ लॉन्च कर सकते हैं. हालांकि, इसके लिए उन्हें 'Android सिक्योरिटी बुलेटिन (एएसबी)' में दी गई एलटीएस (लंबे समय तक सहायता) की ज़रूरी शर्तों का पालन करना होगा.

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

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

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

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

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

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

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

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

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

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

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

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

• हर महीने के बिल्ड की शुरुआती सार्वजनिक रिलीज़ के लॉन्च होने के बाद, सिर्फ़ रिलीज़ शाखाओं पर फिर से स्पिन करने की अनुमति होती है.

• किसी रिलीज़ शाखा के लिए, फिर से स्पिन करने के अनुरोध सिर्फ़ शुरुआती सार्वजनिक रिलीज़ के बाद, ज़्यादा से ज़्यादा छह महीने तक स्वीकार किए जाते हैं. छह महीने के बाद, सिर्फ़ Android Security Bulletin में बताए गए सुरक्षा पैच के लिए, शाखाओं को फिर से सबमिट करने की अनुमति मिलती है.

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

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

• हर महीने की रिलीज़ ब्रांच में जाने वाले सभी पैच, पहले से ही जीकेआई डेवलपमेंट की मुख्य ब्रांच में मर्ज कर दिए जाने चाहिए. उदाहरण के लिए, अगर android12-5.10-2022-09 को फिर से स्पिन करने के लिए पैच की ज़रूरत है, तो उसे पहले से ही android12-5.10 में मर्ज किया जाना चाहिए.

• आपको जीकेआई की डेवलपमेंट ब्रांच से पैच चुनने होंगे और पैच को हर महीने की रिलीज़ ब्रांच में अपलोड करना होगा.

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

  प्राथमिकता	ईएसआरटी
  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 पार्टनर (आप) रिस्पॉन्स का अनुरोध सबमिट करता है.

दूसरी इमेज. फिर से अनुरोध करने की प्रोसेस

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

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

GKI की ज़रूरी शर्तें

बिल्ड आर्टफ़ैक्ट कहां से डाउनलोड किए जा सकते हैं

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

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

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

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

क्या पहले से रिलीज़ किए गए GKI के आधार पर, नया 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 आर्टफ़ैक्ट की कॉपी वापस पा सकते हैं.

क्या GKI बाइनरी (इमरजेंसी स्पिन पैच के साथ) को नए कोडबेस पर बनाया गया है?

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

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

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

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

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

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

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