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

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

GKI रिलीज़ करने की फ़्रीक्वेंसी

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

ओईएम के लिए GKI बिल्ड की वैधता

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

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

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

तीन महीने में एक बार सर्टिफ़ाइड रिलीज़

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

फिर से स्पिन करने की प्रोसेस में शामिल होने के लिए:

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

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

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

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

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

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

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

क्या पहले से रिलीज़ किए गए GKI के आधार पर, नई GKI बाइनरी बनाई जा सकती है?

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

क्या 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 बाइनरी (इसमें इमरजेंसी स्पिन पैच भी शामिल है) को नए कोडबेस पर बनाया गया है?

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

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

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

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

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

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

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