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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्या 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 यह नहीं बताता कि इस समस्या का असर किस डिवाइस पर पड़ा है. हालांकि, ओईएम को बदलाव के लॉग में समस्या के बारे में जानकारी और उसका समाधान हमेशा मिल सकता है.