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

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

GKI रिलीज़ करने का क्रम

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

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

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

16 केबी GKI रिलीज़

GKI रिलीज़ टीम, 16 केबी वाले GKI रिलीज़ को मैनेज करती है. इसके लिए, वह 4 केबी वाले GKI रिलीज़ के लिए इस्तेमाल की जाने वाली प्रोसेस का ही इस्तेमाल करती है. जैसे, हर तीन महीने में रिलीज़ करने का शेड्यूल, ज़रूरी शर्तें पूरी करने की जांच, और फिर से स्पिन करने की प्रोसेस:

• इस्तेमाल की जा सकने वाली शाखाएं:
  • android15-6.6 (जनवरी 2026 से)
  • android16-6.12 (मार्च 2026 से)
  • android17-6.18 (जून 2026 से)
• बिल्ड पैरिटी और सर्टिफ़िकेशन: 16 केबी जीकेआई बाइनरी, उसी सोर्स टैग और कर्नेल बिल्ड आईडी का इस्तेमाल करती हैं जो 4 केबी जीकेआई रिलीज़ के लिए इस्तेमाल किया जाता है. साल 2027 तक, android15-6.6, android16-6.12, और android17-6.18 रिलीज़ के लिए तैयार बिल्ड वाले पेजों पर मौजूद 16 केबी रिलीज़ के लिए तैयार बिल्ड टैब में, 16 केबी वाले GKI रिलीज़ के लिए तैयार बाइनरी उपलब्ध होंगी. हालांकि, ये सर्टिफ़ाइड नहीं होंगी. हालांकि, आपको 4 केबी और 16 केबी कर्नेल को एक साथ अपडेट करने की ज़रूरत नहीं है. हमारा सुझाव है कि आप ऐसा करें.
• मांग पर रीस्पिन: 16 केबी वाले GKI रीस्पिन का अनुरोध करें. इसके लिए, 4 केबी वाले बिल्ड के लिए इस्तेमाल की जाने वाली रीस्पिन अनुरोध की प्रोसेस और फ़ॉर्म का इस्तेमाल करें.

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

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

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

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

GKI से जुड़ी ज़रूरी शर्तें

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

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

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

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

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

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

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

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

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

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 की अगली तिमाही रिलीज़ में भी शामिल हैं.

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

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

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

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

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