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

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

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

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

ध्यान दें: (*) का मतलब है कि यह 16K की सुविधा के साथ काम करता है.

रिलीज़ होने का महीना		a12-5.10	a13-5.10	a13-5.15	a14-5.15	a14-6.1	a15-6.6*	a16-6.12*	a17-6.18*
अक्टूबर 2025	चेक-इन करने की समयसीमा		16 अक्टूबर		1 अक्टू॰		1 अक्टू॰
	GKI को पहले से लोड करने की सुविधा चालू है		31 अक्टूबर		15 अक्टूबर		15 अक्टूबर
दिसंबर 2025	चेक-इन करने की समयसीमा	1 दिसं॰		1 दिसं॰		1 दिसं॰		1 दिसं॰
	GKI को पहले से लोड करने की सुविधा चालू है	15 दिसं॰		15 दिसं॰		15 दिसं॰		15 दिसं॰
जनवरी 2026	चेक-इन करने की समयसीमा		16 जनवरी		2 जन॰		2 जन॰
	GKI को पहले से लोड करने की सुविधा चालू है		31 जनवरी		15 जन॰		15 जन॰
फ़रवरी 2026	चेक-इन करने की समयसीमा
	GKI को पहले से लोड करने की सुविधा चालू है
मार्च 2026	चेक-इन करने की समयसीमा			1 मार्च		1 मार्च		मार्च 15
	GKI को पहले से लोड करने की सुविधा चालू है			मार्च 15		मार्च 15		31 मार्च
अप्रैल 2026	चेक-इन करने की समयसीमा	16 अप्रैल	16 अप्रैल		1 अप्रैल		1 अप्रैल
	GKI को पहले से लोड करने की सुविधा चालू है	30 अप्रैल	30 अप्रैल		अप्रैल 15		अप्रैल 15
मई 2026	चेक-इन करने की समयसीमा
	GKI को पहले से लोड करने की सुविधा चालू है
जून 2026	चेक-इन करने की समयसीमा			1 जून		15 जून		15 जून	1 जून
	GKI को पहले से लोड करने की सुविधा चालू है			15 जून		30 जून		30 जून	15 जून
जुलाई 2026	चेक-इन करने की समयसीमा	16 जुलाई	16 जुलाई		1 जुलाई		1 जुलाई
	GKI को पहले से लोड करने की सुविधा चालू है	31 जुलाई	31 जुलाई		15 जुलाई		15 जुलाई
अगस्त 2026	चेक-इन करने की समयसीमा
	GKI को पहले से लोड करने की सुविधा चालू है
सितंबर 2026	चेक-इन करने की समयसीमा			1 सितं॰		16 सितंबर		16 सितंबर	1 सितं॰
	GKI को पहले से लोड करने की सुविधा चालू है			15 सितंबर		30 सितंबर		30 सितंबर	15 सितंबर
अक्टूबर 2026	चेक-इन करने की समयसीमा	16 अक्टूबर	16 अक्टूबर		1 अक्टू॰		1 अक्टू॰
	GKI को पहले से लोड करने की सुविधा चालू है	31 अक्टूबर	31 अक्टूबर		15 अक्टूबर		15 अक्टूबर
नवंबर 2026	चेक-इन करने की समयसीमा
	GKI को पहले से लोड करने की सुविधा चालू है
दिसंबर 2026	चेक-इन करने की समयसीमा			1 दिसं॰		1 दिसं॰		1 दिसं॰	1 दिसं॰
	GKI को पहले से लोड करने की सुविधा चालू है			15 दिसं॰		15 दिसं॰		15 दिसं॰	15 दिसं॰

OEM के लिए जीकेआई बिल्ड की वैधता

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

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

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

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

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

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

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

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

OEM, 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, ओईएम पैच और समस्या के उदाहरणों के बारे में खास जानकारी देता है, ताकि ओईएम अपने प्रॉडक्ट में पैच लागू करने के असर और जोखिम का आकलन कर सकें?

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