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

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

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

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

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

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

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

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

इमरजेंसी रिस्पॉन्स प्रोसेस

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

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

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

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

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

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

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

• जब Android Security Bulletin (ASB) के मुताबिक तय की गई LTS की ज़रूरी शर्तें पूरी न की जा रही हों, तो उस शाखा को बंद कर दिया जाता है. बंद की गई शाखाओं के लिए, फिर से स्पिन करने के अनुरोध स्वीकार नहीं किए जाते. किसी 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 पार्टनर (आप) फिर से अनुरोध सबमिट करता है.

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

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

1. GKI के लिए फिर से अनुरोध करने का फ़ॉर्म भरें. इसके बाद, अपने Google तकनीकी खाता मैनेजर से तुरंत संपर्क करें. इस फ़ॉर्म से, GKI के अनुरोध को अस्वीकार करने से जुड़ी गड़बड़ी पैदा होती है. फिर से स्पिन करने का अनुरोध करने वाले बग, आपको (अनुरोध करने वाले), GKI टीम, और उन खास लोगों को दिखते हैं जिन्हें आपने बग की कॉपी भेजने की सूची में जोड़ा है.
   • अगर आपने पहले ही गड़बड़ी को ठीक कर लिया है, तो अनुरोध में AOSP में सबमिट किए गए पैच के बारे में बताया जाना चाहिए, ताकि Google उसकी समीक्षा कर सके. अगर पैच सबमिट करना संभव नहीं है, तो पैच को अनुरोध में टेक्स्ट फ़ाइल के तौर पर अटैच करना होगा.
   • अगर आपके पास समस्या को ठीक करने का तरीका नहीं है, तो अनुरोध में ज़्यादा से ज़्यादा जानकारी होनी चाहिए. इसमें, कर्नेल वर्शन नंबर और लॉग शामिल होने चाहिए, ताकि Google समस्या को डीबग करने में आपकी मदद कर सके.
2. Google GKI टीम, अनुरोध की समीक्षा करती है और उसे स्वीकार करती है. अगर ज़्यादा जानकारी की ज़रूरत पड़ती है, तो वह अनुरोध को फिर से आपको असाइन कर देती है.
3. समस्या को ठीक करने के लिए सहमति मिलने के बाद, Google GKI टीम कोड की समीक्षा करती है (CR+2). समीक्षा की प्रक्रिया शुरू होने के बाद, ईएसआरटी की समयसीमा शुरू हो जाती है. GKI टीम, मर्ज करती है, बनाती है, और रिग्रेशन के लिए जांच करती है. साथ ही, बदलाव की पुष्टि करती है.
4. बाइनरी को ci.android.com पर रिलीज़ किया जाता है. इसके बाद, ईएसआरटी की समयसीमा खत्म हो जाती है और Google GKI टीम, अनुरोध को ठीक के तौर पर मार्क कर देती है. साथ ही, फिर से भेजे गए बिल्ड का रेफ़रंस देती है. फिर से भेजा गया बिल्ड, Generic Kernel Image (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 के लिए" respin पाथ को स्केल नहीं किया जा सकता. इसके बजाय, GKI टीम, रिस्पॉन्सिव बिल्ड में किए गए हर बदलाव की जांच करती है. साथ ही, नया बिल्ड बनाने से पहले, सभी उपलब्ध हार्डवेयर के साथ बदलावों की जांच करती है. अगर GKI टीम को पता चलता है कि समस्या किसी OEM, डिवाइस या मॉडल से जुड़ी है, तो GKI टीम यह पक्का कर सकती है कि बदलाव से जोड़ा गया कोड सिर्फ़ उस डिवाइस, मॉडल या SKU पर लागू हो जिस पर असर पड़ा है.

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

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

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