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

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

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

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

OEM के लिए GKI बिल्ड की वैधता

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