जेनेरिक कर्नेल इमेज (जीकेआई) रिलीज प्रक्रिया

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

जीकेआई रिलीज़ ताल

KMI फ़्रीज़ होने के बाद GKI को मासिक ताल पर जारी किया जाता है।

एंड्रॉइड 13 और 14 जीकेआई रिलीज

निम्न तालिका केवल android13-5.10 , android13-5.15 , और android14-6.1 पर लागू है।

GKI मासिक प्रमाणित बिल्ड चेक-इन की अंतिम तिथि GKI प्रीलोड तैयार तिथि की पुष्टि की?
अक्टूबर 14 अक्टूबर 2022 31 अक्टूबर 2022 हाँ
नवंबर 14 नवंबर 2022 30 नवंबर 2022 हाँ
दिसंबर 9 दिसंबर 2022 21 दिसंबर 2022 हाँ
जनवरी 17 जनवरी 2023 31 जनवरी 2023 हाँ
फ़रवरी 15 फ़रवरी 2023 28 फ़रवरी 2023 हाँ
मार्च 15 मार्च 2023 31 मार्च 2023 हाँ
अप्रैल 13 अप्रैल 2023 28 अप्रैल 2023 हाँ
मई 17 मई 2023 31 मई 2023 हाँ
जून 15 जून 2023 30 जून 2023 हाँ
जुलाई 18 जुलाई 2023 31 जुलाई 2023 हाँ
अगस्त 16 अगस्त 2023 31 अगस्त 2023 हाँ
सितम्बर 14 सितंबर 2023 29 सितंबर 2023 हाँ
अक्टूबर 18 अक्टूबर 2023 31 अक्टूबर 2023 हाँ
नवंबर 10 नवंबर 2023 30 नवंबर 2023 हाँ
दिसंबर 7 दिसंबर 2023 22 दिसंबर 2023 हाँ
जनवरी 16 जनवरी 2024 31 जनवरी 2024 हाँ
फ़रवरी 13 फ़रवरी 2024 29 फरवरी 2024 हाँ
मार्च 13 मार्च 2024 29 मार्च 2024 हाँ
अप्रैल 16 अप्रैल 2024 30 अप्रैल 2024 हाँ
मई 14 मई 2024 31 मई 2024 हाँ
जून 12 जून 2024 28 जून 2024 हाँ
जुलाई 16 जुलाई 2024 31 जुलाई 2024 हाँ
अगस्त 15 अगस्त 2024 30 अगस्त 2024 हाँ
सितम्बर 17 सितंबर 2024 30 सितंबर 2024 हाँ
अक्टूबर 15 अक्टूबर 2024 31 अक्टूबर 2024 हाँ
नवंबर 11 नवंबर 2024 27 नवंबर 2024 हाँ
दिसंबर 6 दिसंबर 2024 23 दिसंबर 2024 हाँ

जनवरी 2024 से, हम नीचे दी गई तालिका में उल्लिखित निर्दिष्ट मासिक ताल के अनुसार android14-5.15 की मासिक रिलीज़ फिर से शुरू करेंगे।

GKI मासिक प्रमाणित बिल्ड चेक-इन की अंतिम तिथि GKI प्रीलोड तैयार तिथि की पुष्टि की?
जनवरी 16 जनवरी 2024 31 जनवरी 2024 हाँ
फ़रवरी 13 फ़रवरी 2024 29 फरवरी 2024 हाँ
मार्च 4 मार्च 2024 15 मार्च 2024 हाँ
अप्रैल 1 अप्रैल 2024 17 अप्रैल 2024 हाँ
मई 1 मई 2024 17 मई 2024 हाँ
जून 3 जून 2024 17 जून 2024 हाँ
जुलाई 1 जुलाई 2024 15 जुलाई 2024 हाँ
अगस्त 1 अगस्त 2024 16 अगस्त 2024 हाँ
सितम्बर 2 सितंबर 2024 16 सितंबर 2024 हाँ
अक्टूबर 1 अक्टूबर 2024 14 अक्टूबर 2024 हाँ
नवंबर 1 नवंबर 2024 15 नवंबर 2024 हाँ
दिसंबर 2 दिसंबर 2024 16 दिसंबर 2024 हाँ

एंड्रॉइड 12 जीकेआई रिलीज़

मई 2023 के बाद, android12-5.10 GKI रिलीज़ 2 महीने की लय पर हैं और महीने के मध्य में प्रकाशित होते हैं। निम्न तालिका केवल android12-5.10 पर लागू है।

GKI मासिक प्रमाणित बिल्ड चेक-इन की अंतिम तिथि GKI प्रीलोड तैयार तिथि की पुष्टि की?
जुलाई 3 जुलाई 2023 14 जुलाई 2023 हाँ
सितम्बर 1 सितंबर 2023 15 सितंबर 2023 हाँ
नवंबर 3 नवंबर 2023 17 नवंबर 2023 हाँ
जनवरी 5 जनवरी 2024 19 जनवरी 2024 हाँ
मार्च 4 मार्च 2024 15 मार्च 2024 हाँ
मई 1 मई 2024 17 मई 2024 हाँ

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

OEM हाल ही में जारी Android GKI का उपयोग कर सकते हैं। ओईएम जीकेआई-प्रमाणित बिल्ड के साथ तब तक लॉन्च कर सकते हैं जब तक वे एंड्रॉइड सुरक्षा बुलेटिन (एएसबी) में एलटीएस आवश्यकताओं के अनुरूप हैं।

साप्ताहिक विकास विज्ञप्ति

रिलीज का परीक्षण कटलफिश के साथ किया जाता है ताकि यह सुनिश्चित किया जा सके कि वे न्यूनतम गुणवत्ता बार पास करते हैं।

परिवर्तन मर्ज होते ही GKI बायनेरिज़ ci.android.com से स्वयं-सेवा के लिए उपलब्ध हैं। साप्ताहिक बिल्ड को प्रमाणित नहीं किया जाएगा, हालाँकि इसे विकास और परीक्षण के लिए आधार रेखा के रूप में उपयोग किया जा सकता है। साप्ताहिक बिल्ड का उपयोग अंतिम उपयोगकर्ताओं के लिए उत्पादन उपकरण निर्माण के लिए नहीं किया जा सकता है।

मासिक प्रमाणित विज्ञप्ति

GKI मासिक रिलीज़ में एक परीक्षण किया गया boot.img होता है जिसमें यह प्रमाणित करने के लिए एक Google सम्मिलित प्रमाणपत्र शामिल होता है कि बायनेरिज़ एक ज्ञात स्रोत कोड बेसलाइन से बनाए गए थे।

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

जीकेआई ने ताल समयरेखा जारी की चित्र 1. जीकेआई रिलीज़ टाइमलाइन

आपातकालीन प्रतिक्रिया प्रक्रिया

रिस्पिन जीकेआई कर्नेल की सार्वजनिक रिलीज के बाद बाइनरी को फिर से मर्ज करने, पुनर्निर्माण करने, पुन: परीक्षण करने और पुन: प्रमाणित करने की प्रक्रिया को संदर्भित करता है। आप निम्नलिखित में से किसी भी परिस्थिति के लिए प्रमाणित बाइनरी के रिस्पिन का अनुरोध कर सकते हैं:

  • प्रतीक सूची को अद्यतन करने के लिए.
  • किसी बग का समाधान लागू करने के लिए, जिसमें कैरियर लैब अनुमोदन के दौरान पाए गए बग भी शामिल हैं।
  • एक विक्रेता हुक जोड़ने के लिए.
  • किसी मौजूदा सुविधा पर पैच लागू करने के लिए.
  • सुरक्षा पैच लागू करने के लिए (6 महीने के बाद)।

शाखा के रिलीज़ होने के 6 महीने बाद तक सुरक्षा पैच स्वचालित रूप से रिलीज़ शाखा में विलय हो जाते हैं। 6 महीने की कटऑफ के बाद, आपको किसी शाखा में सुरक्षा पैच लागू करने के लिए रिस्पिन का अनुरोध करना होगा।

प्रतिक्रिया का अनुरोध करने से पहले, निम्नलिखित दिशानिर्देशों पर ध्यान दें:

  • मासिक बिल्ड की आरंभिक सार्वजनिक रिलीज़ लॉन्च होने के बाद केवल रिलीज़ शाखाओं पर रिस्पिन की अनुमति दी जाती है।

  • प्रारंभिक सार्वजनिक रिलीज़ के बाद अधिकतम छह महीने के लिए रिस्पिन अनुरोध केवल दी गई रिलीज़ शाखा के लिए स्वीकार किए जाते हैं। छह महीने के बाद, शाखाएं केवल एंड्रॉइड सुरक्षा बुलेटिन में उद्धृत सुरक्षा पैच के लिए प्रतिक्रिया के लिए पात्र हैं।

  • जब एंड्रॉइड सुरक्षा बुलेटिन (एएसबी) द्वारा परिभाषित एलटीएस आवश्यकताएं शाखा के गैर-अनुपालन का कारण बनती हैं, तो शाखा को हटा दिया जाता है। अप्रचलित शाखाओं के लिए रिस्पिन अनुरोध स्वीकार नहीं किए जाते हैं। किसी दी गई GKI रिलीज़ शाखा के लिए अवमूल्यन तिथि को रिलीज़ के अंतर्गत मासिक GKI रिलीज़ बिल्ड नोट्स में शामिल किया गया है। भविष्य की योजना के लिए, एलटीएस आवश्यकताओं को सालाना मई और नवंबर में अद्यतन किया जाता है। उदाहरण के लिए, android12-5.10-2023-07 शाखा (5.10.177) 1 मई 2024 के बाद रिस्पिन के लिए समर्थित नहीं है, क्योंकि android12-5.10-2023-07 शाखा (5.10.177) इसका अनुपालन नहीं करती है। एएसबी-2024-05 की एलटीएस आवश्यकताएँ।

  • रिस्पिन्स केवल तत्काल बग फिक्स, प्रतीक सूची अपडेट, या किसी मौजूदा सुविधा को ठीक करने के लिए पैच लागू करने के लिए लागू होते हैं।

  • मासिक रिलीज़ शाखा में जाने वाले सभी पैच को पहले ही मुख्य GKI विकास शाखा में विलय कर दिया जाना चाहिए। उदाहरण के लिए, यदि android12-5.10-2022-09 के रिस्पिन के लिए पैच की आवश्यकता है, तो इसे पहले से ही android12-5.10 में मर्ज किया जाना चाहिए।

  • आपको मुख्य GKI विकास शाखा से पैच चुनना होगा और पैच को मासिक रिलीज़ शाखा में अपलोड करना होगा।

  • रिस्पिन अनुरोध में, आपको अनुरोध को प्राथमिकता (तत्कालता) निर्दिष्ट करनी होगी। यह प्राथमिकता जीकेआई टीम को समय पर साझेदारों की बेहतर सहायता करने में मदद करती है। महत्वपूर्ण या समय-संवेदनशील अनुरोधों के लिए, प्राथमिकता को P0 के रूप में चिह्नित करें। P0 और P1 अनुरोधों के लिए, आपको तात्कालिकता का औचित्य भी बताना होगा। निम्न तालिका बग प्राथमिकता और समाधान के समय (ईएसआरटी) की मैपिंग प्रदान करती है:

    प्राथमिकता ईएसआरटी
    प0 2 व्यावसायिक दिन
    पी1 5 व्यावसायिक दिन
    पी2 10 व्यावसायिक दिन
    पी 3 15 व्यावसायिक दिन
  • आपको प्रत्येक रिलीज़ शाखा के लिए एक अलग रिस्पिन अनुरोध सबमिट करना होगा। उदाहरण के लिए, यदि android12-5.10-2022-08 और android12-5.10-2022-09 दोनों के लिए एक रिस्पिन की आवश्यकता है, तो आपको दो रिस्पिन अनुरोध बनाने होंगे।

  • बिल्ड प्रदान किए जाने और रिस्पिन अनुरोध को निश्चित के रूप में चिह्नित किए जाने के बाद, आपको अतिरिक्त सीएल जोड़ने के लिए रिस्पिन अनुरोध को दोबारा नहीं खोलना चाहिए। यदि अतिरिक्त पैच हैं जिन्हें मर्ज करने की आवश्यकता है तो आपको एक नया रिस्पिन अनुरोध सबमिट करना होगा।

  • विचाराधीन प्रत्येक सीएल के लिए, निम्नलिखित टैग जोड़ें। इस जानकारी के बिना रिस्पिन अनुरोध पर प्रगति अवरुद्ध है।

    • Bug : बग आईडी को प्रत्येक सीएल के लिए प्रतिबद्ध संदेश में जोड़ा जाना चाहिए।
    • Change-Id : आधार शाखा परिवर्तन की Change-Id के समान होना चाहिए।
  • यदि रिस्पिन अनुरोध के लिए आपकी प्रतिक्रिया की आवश्यकता होती है, और आप तीन व्यावसायिक दिनों के भीतर जवाब नहीं देते हैं, तो प्राथमिकता एक स्तर से डाउनग्रेड हो जाती है (उदाहरण के लिए, P0 को P1 पर डाउनग्रेड कर दिया जाता है)। यदि आप दो सप्ताह तक जवाब नहीं देते हैं, तो बग को ठीक नहीं किया जाएगा (अप्रचलित) के रूप में चिह्नित किया जाता है।

रिस्पिन अनुरोध सबमिट करें

निम्नलिखित चित्र रिस्पिन प्रक्रिया को दर्शाता है। प्रक्रिया तब शुरू होती है जब ओईएम पार्टनर (आप) रिस्पिन अनुरोध सबमिट करता है।

आपातकालीन प्रतिक्रिया प्रक्रिया चित्र 2. रिस्पिन प्रक्रिया

रिस्पिन प्रक्रिया में प्रवेश करने के लिए:

  1. जीकेआई रेस्पिन अनुरोध फॉर्म भरें । और तुरंत अपने Google तकनीकी खाता प्रबंधक से संपर्क करें। यह फॉर्म GKI रिस्पिन अनुरोध बग बनाता है। रिस्पिन अनुरोध बग आपको (अनुरोधकर्ता), जीकेआई टीम और विशिष्ट व्यक्तियों को दिखाई देते हैं जिन्हें आप बग की सीसी सूची में जोड़ते हैं।
    • यदि आपके पास पहले से ही कोई समाधान है, तो अनुरोध को AOSP में पैच सबमिटल को इंगित करना चाहिए ताकि Google इसकी समीक्षा कर सके। यदि पैच सबमिट करना संभव नहीं है, तो पैच को अनुरोध के साथ एक टेक्स्ट फ़ाइल के रूप में संलग्न किया जाना चाहिए।
    • यदि आपके पास कोई समाधान नहीं है, तो अनुरोध में कर्नेल संस्करण संख्या और लॉग सहित यथासंभव अधिक जानकारी होनी चाहिए, ताकि Google समस्या को सुलझाने में मदद कर सके।
  2. Google GKI टीम अनुरोध की समीक्षा करती है और इसे स्वीकृत करती है या अधिक जानकारी की आवश्यकता होने पर इसे आपको वापस सौंप देती है।
  3. किसी समाधान पर सहमति होने के बाद, Google GKI टीम कोड परिवर्तन की समीक्षा (CR+2) करती है। समीक्षा ईएसआरटी समयसीमा शुरू करती है। जीकेआई टीम विलय करती है, निर्माण करती है, प्रतिगमन के लिए परीक्षण करती है और परिवर्तन को प्रमाणित करती है।
  4. बाइनरी ci.android.com पर जारी की गई है। ईएसआरटी समय सीमा समाप्त हो जाती है और Google GKI टीम अनुरोध को तय के रूप में चिह्नित करती है और रिस्पिन बिल्ड का संदर्भ देती है। रेस्पिन बिल्ड को जेनेरिक कर्नेल इमेज (जीकेआई) रिलीज बिल्ड पेज पर भी पोस्ट किया गया है।

जीकेआई योग्यता

जीकेआई बिल्ड के प्रकार गुणवत्ता प्रवर्तन टिप्पणियाँ
साप्ताहिक कटलफिश परीक्षण
  • गाड़ी की डिक्की
  • वीटीएस का सबसेट
  • सीटीएस का सबसेट
  • प्रमाणित नहीं. केवल परीक्षण के लिए और
    डिवाइस ऊपर लाओ.
  • डिवाइस लॉन्च करने के लिए उपयोग नहीं किया जा सकता.
मासिक (प्रमाणित) कटलफिश परीक्षण
  • गाड़ी की डिक्की
  • वीटीएस
  • सीटीएस
संदर्भ हार्डवेयर परीक्षण
  • गाड़ी की डिक्की
  • वीटीएस
  • सीटीएस
    रिस्पिन्स (प्रमाणित) कटलफिश परीक्षण
    • गाड़ी की डिक्की
    • वीटीएस
    • सीटीएस का सबसेट
    संदर्भ उपकरण परीक्षण
    • गाड़ी की डिक्की
    • वीटीएस
    • GKI प्रमाणित बिल्ड के शीर्ष पर निर्मित।
    • योग्यता के बाद निर्माण को प्रमाणित किया जाता है।

    निर्मित कलाकृतियाँ कहाँ से प्राप्त करें

    सभी रिलीज़ों के लिए कलाकृतियाँ ci.android.com से प्राप्त की जा सकती हैं।

    आप एंड्रॉइड कंटीन्यूअस इंटीग्रेशन डैशबोर्ड पर परीक्षण परिणामों सहित सीआई पर अधिक जानकारी पा सकते हैं।

    पूछे जाने वाले प्रश्न

    क्या पहले से जारी GKI के आधार पर एक नई GKI बाइनरी बनाना संभव है?

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

    क्या 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
    

    आप अपनी GKI आर्टिफैक्ट कॉपी को out/.../dist से पुनः प्राप्त कर सकते हैं।

    क्या GKI बाइनरी (आपातकालीन स्पिन पैच सहित) नवीनतम कोडबेस पर बनाया गया है?

    नहीं, रेस्पिन में केवल वे पैच होते हैं जो चुने गए मासिक प्रमाणित कर्नेल के शीर्ष पर होते हैं। इन रिस्पिन्स में ओईएम द्वारा संबंधित आधार मासिक रिलीज का उपयोग करके किसी भी समय तक रिपोर्ट किए गए सभी लॉन्च ब्लॉकिंग बग फिक्स शामिल हैं। इस प्रकार का परिदृश्य कैसे घटित होता है, इसका निम्नलिखित उदाहरण देखें।

    • OEM1 और OEM2 ने नवंबर 2021 से GKI बाइनरी रिलीज़ का उपयोग करने का निर्णय लिया है।
    • OEM1 और OEM2 ऐसे मुद्दे ढूंढते हैं जिनके लिए समर्थन के लिए पैच की आवश्यकता होती है। ये पैच अलग-अलग हो सकते हैं या एक जैसे भी हो सकते हैं.
    • नवंबर 2021 बाइनरी के शीर्ष पर रिस्पिन में रिस्पिन विंडो के दौरान OEM1 और OEM2 दोनों द्वारा रिपोर्ट किए गए लॉन्च ब्लॉकिंग फिक्स हैं, लेकिन इससे अधिक कुछ नहीं।
    • दूसरे बुलेट में उल्लिखित मुद्दों को बाद की जीकेआई मासिक रिलीज में भी शामिल किया गया है।

    अक्टूबर रिस्पिन में सभी ओईएम सबमिट किए गए पैच हैं, लेकिन अन्य ओईएम पैच हमें प्रभावित करते हैं, क्योंकि उनका हमारे उत्पादों के साथ विशेष रूप से परीक्षण नहीं किया गया है। क्या केवल हमारे पैच को शामिल करना संभव है?

    ऐसा नहीं हो सकता। एक "प्रति-ओईएम" रिस्पिन पथ वर्तमान में स्केलेबल नहीं है। इसके बजाय, जीकेआई टीम रेस्पिन बिल्ड में होने वाले हर एक बदलाव की जांच करती है, और नया बिल्ड बनाने से पहले सभी उपलब्ध हार्डवेयर के साथ परिवर्तनों का परीक्षण करती है। यदि GKI टीम को पता चलता है कि समस्या OEM/डिवाइस/मॉडल के लिए विशिष्ट है, तो GKI टीम यह सुनिश्चित कर सकती है कि परिवर्तन द्वारा जोड़ा गया कोड केवल प्रभावित होने वाले डिवाइस/मॉडल/SKU पर निष्पादित होता है।

    एकीकृत रिस्पिन्स का प्रमुख लाभ यह है कि समान रिलीज़ बेस का उपयोग करने वाले प्रत्येक डिवाइस को एक-दूसरे से लाभ होता है, खासकर यदि उनके द्वारा खोजे गए बग सामान्य हैं और सभी उपयोगकर्ताओं पर लागू होते हैं। वाहक परीक्षण में पाए गए कोर कर्नेल बग इस अवधारणा का एक विशिष्ट उदाहरण हैं।

    क्या ऐसी स्थितियाँ हैं जहाँ Google OEM पैच और समस्या परिदृश्यों के बारे में विशिष्ट जानकारी प्रदान करता है, ताकि OEM अपने उत्पादों के साथ पैच लागू करने के प्रभाव और जोखिम का मूल्यांकन कर सकें?

    जब तक समस्या समझ में नहीं आ जाती और सभी विवरण एकत्र नहीं कर लिए जाते, Google कभी भी रिस्पिन बिल्ड में कोई बदलाव नहीं करेगा। इसे चेंजलॉग (कमिट मैसेज) में देखा जा सकता है। Google यह नहीं बताता कि यह किस विशिष्ट डिवाइस को प्रभावित करता है, लेकिन OEM हमेशा चेंजलॉग में समस्या का विवरण और समाधान पा सकते हैं।