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

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

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

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

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

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

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

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

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

पहली इमेज. GKI रिलीज़ करने की समयावधि

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

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

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

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