इस दस्तावेज़ में बताया गया है कि जीकेआई कैसे रिलीज़ किया जाता है. इसमें हर हफ़्ते, हर महीने, और बिना बैंड के अचानक होने वाली रिलीज़ शामिल हैं. इस दस्तावेज़ का मकसद, ओईएम को यह दिशा-निर्देश देना है कि वे जीकेआई (जीकेआई) से जुड़ी जानकारी कहां से हासिल कर सकें. साथ ही, बैंड की आपातकालीन स्थितियों में सुधार करने की प्रोसेस कैसे शुरू की जा सकती है. OEM इस बारे में ज़्यादा जानने के लिए जीकेआई डेवलपमेंट गाइड का भी इस्तेमाल कर सकते हैं कि वे Android Kernel टीम के साथ काम करके, अपने प्रॉडक्ट के लिए GKI कर्नेल को ऑप्टिमाइज़ कैसे कर सकते हैं.
जीकेआई रिलीज़ की फ़्रीक्वेंसी
केएमआई की पाबंदी के बाद 'जीकेआई' को हर महीने के हिसाब से रिलीज़ किया जाता है.
Android 13, 14, और 15 जीकेआई रिलीज़
नीचे दी गई टेबल सिर्फ़ android13-5.10
, android13-5.15
, और android14-6.1
पर लागू होती है.
जीकेआई की ओर से हर महीने प्रमाणित किए जाने वाले बिल्ड | चेक इन करने की कट ऑफ़ तारीख | 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
की हर महीने की रिलीज़ फिर से शुरू करेंगे. ऐसा नीचे दी गई टेबल में बताए गए महीने के हिसाब से किया जाएगा.
साल 2024 की शुरुआत में, android15-6.6
के कॉन्टेंट को रिलीज़ करने के क्रम में बदलाव किए जाएंगे.
जीकेआई की ओर से हर महीने प्रमाणित किए जाने वाले बिल्ड | चेक इन करने की कट ऑफ़ तारीख | 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 | हां |
Android 12 जीकेआई की रिलीज़
मई 2024 के बाद, android12-5.10
जीकेआई की रिलीज़ तिमाही के हिसाब से जारी की जाएंगी और इन्हें महीने के बीच में पब्लिश किया जाएगा.
नीचे दी गई टेबल सिर्फ़ android12-5.10
पर लागू होती है.
जीकेआई की ओर से हर महीने प्रमाणित किए जाने वाले बिल्ड | चेक इन करने की कट ऑफ़ तारीख | 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 | हां |
अगस्त | 1 अगस्त, 2024 | 16 अगस्त, 2024 | हां |
नवंबर | 1 नवंबर, 2024 | 15 नवंबर, 2024 | हां |
फ़रवरी | 3 फ़रवरी, 2025 | 17 फ़रवरी, 2025 | हां |
OEM के लिए जीकेआई बिल्ड वैलिडिटी
OEM, हाल ही में रिलीज़ किए गए Android GKI का इस्तेमाल कर सकते हैं. ओईएम, जीकेआई से सर्टिफ़ाइड बिल्ड के साथ लॉन्च कर सकते हैं. हालांकि, इसके लिए उन्हें Android सिक्योरिटी बुलेटिन (एएसबी) में दी गई एलटीएस (लंबे समय तक सहायता) की ज़रूरी शर्तों का पालन करना होगा.
हर हफ़्ते होने वाले डेवलपमेंट की रिलीज़
रिलीज़ की जांच कटलफ़िश की मदद से की जाती है, ताकि यह पक्का किया जा सके कि वे कम से कम क्वालिटी के मानकों के मुताबिक हैं.बदलावों को मर्ज कर दिया गया है, इसलिए ci.android.com पर, GKI बाइनरी फ़ाइलें सेल्फ़-सर्विस के लिए उपलब्ध हैं. हर हफ़्ते के बिल्ड प्रमाणित नहीं किए जाएंगे. हालांकि, इनका इस्तेमाल डेवलपमेंट और टेस्टिंग के लिए बेसलाइन के तौर पर किया जा सकता है. असली उपयोगकर्ताओं के लिए, हर हफ़्ते के बिल्ड का इस्तेमाल प्रोडक्शन डिवाइस बिल्ड के लिए नहीं किया जा सकता.
हर महीने सर्टिफ़ाइड रिलीज़
हर महीने Gकेआई की रिलीज़ में जांची गई boot.img
शामिल होती है. इसमें Google का डाला गया सर्टिफ़िकेट शामिल होता है, ताकि यह पुष्टि की जा सके कि बाइनरी, जाने-पहचाने सोर्स कोड बेसलाइन से बनाई गई हैं.
हर महीने, जीकेआई की रिलीज़ के लिए एक कैंडिडेट (जो सर्टिफ़ाइड नहीं है) को चेक-इन के कट ऑफ़ तारीख के बाद चुना जाता है. यह आम तौर पर, उस महीने के दूसरे हफ़्ते में तैयार होने वाली तारीख होती है. हर महीने की रिलीज़ के लिए कैंडिडेट चुने जाने के बाद, उस महीने की रिलीज़ में नए बदलाव स्वीकार नहीं किए जाएंगे. विंडो बंद होने की अवधि के दौरान, सिर्फ़ उन गड़बड़ियों को ठीक किया जा सकता है जिनकी वजह से टेस्ट नहीं हो पाया. रिलीज़ के लिए तैयार किए गए कैंडिडेट की क्वालिटी अश्योरेंस, जीकेआई क्वालीफ़िकेशन सेक्शन में दी गई जानकारी के मुताबिक की जाती है. इससे यह पक्का किया जाता है कि जीएसआई+जीकेआई बिल्ड के लिए ज़रूरी शर्तों का पालन किया जा रहा है. साथ ही, उन्हें कटलफ़िश और एक रेफ़रंस डिवाइस की मदद से टेस्ट पास किया जा सकता है.
पहली इमेज. जीकेआई की रिलीज़ की टाइमलाइन
आपातकालीन स्थिति में फिर से स्पिन करने की प्रोसेस
रेस्पिन का मतलब है, जीकेआई कर्नेल के सार्वजनिक रिलीज़ के बाद, बाइनरी को फिर से मर्ज करने, बनाने, उसकी दोबारा जांच करने, और उसे दोबारा प्रमाणित करने की प्रोसेस. यहां दी गई किसी भी स्थिति में, सर्टिफ़ाइड बाइनरी को बदलने का अनुरोध किया जा सकता है:
- सिंबल की सूची अपडेट करने के लिए.
- किसी गड़बड़ी को ठीक करने के लिए. इसमें मोबाइल और इंटरनेट सेवा देने वाली कंपनी के लैब से मंज़ूरी मिलने के दौरान मिली गड़बड़ियां भी शामिल हैं.
- वेंडर हुक जोड़ने के लिए.
- किसी मौजूदा सुविधा में पैच लागू करने के लिए.
- सिक्योरिटी पैच लागू करने के लिए (छह महीनों के बाद).
ब्रांच के रिलीज़ होने के बाद, सिक्योरिटी पैच को अपने-आप रिलीज़ ब्रांच में छह महीने तक मर्ज कर दिया जाता है. छह महीने के कटऑफ़ के बाद, किसी ब्रांच पर सिक्योरिटी पैच लागू करने के लिए, आपको रीस्पिन का अनुरोध करना होगा.
रिस्पॉन्स का अनुरोध करने से पहले, इन दिशा-निर्देशों पर ध्यान दें:
किसी महीने के बिल्ड के शुरुआती सार्वजनिक रिलीज़ के लॉन्च होने के बाद ही, रिलीज़ ब्रांच पर रीस्पिन की अनुमति है.
रिलीज़ की किसी खास ब्रांच के लिए ही, रिस्पॉन्स के अनुरोध सार्वजनिक तौर पर रिलीज़ करने के बाद छह महीनों तक स्वीकार किए जाते हैं. छह महीनों के बाद, ब्रांच को सिर्फ़ उन सुरक्षा पैच के लिए फिर से इस्तेमाल किया जा सकता है जिनके बारे में Android सुरक्षा बुलेटिन में बताया गया है.
जब Android सिक्योरिटी बुलेटिन (एएसबी) में बताई गई एलटीएस की ज़रूरी शर्तों की वजह से ब्रांच, नीतियों का पालन नहीं करती है, तो ब्रांच को बंद कर दिया जाता है. काम न करने वाली ब्रांच के लिए, रिस्पॉन्स में बदलाव करने के अनुरोध स्वीकार नहीं किए जाते. जीकेआई की रिलीज़ वाली ब्रांच के बंद होने की तारीख, रिलीज़ सेक्शन में हर महीने के जीकेआई रिलीज़ बिल्ड नोट में शामिल होती है. आने वाले समय की योजना के लिए, एलटीएस की शर्तों को हर साल मई और नवंबर में अपडेट किया जाता है. उदाहरण के लिए,
android12-5.10-2023-07
की ब्रांच (5.10.177) पर 1 मई, 2024 के बाद, रिस्पॉन्स मिलने की सुविधा काम नहीं करेगी. इसकी वजह यह है किandroid12-5.10-2023-07
ब्रांच (5.10.177) ASB-2024-05 की एलटीएस (लंबे समय तक सहायता) की शर्तों का पालन नहीं करती.रेस्पिन का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब गड़बड़ियां ठीक की गई हों, सिंबल की सूची अपडेट की गई हो या किसी मौजूदा सुविधा को ठीक करने के लिए पैच लागू किया गया हो.
हर महीने की रिलीज़ ब्रांच में जाने वाले सभी पैच, पहले से ही मुख्य जीकेआई डेवलपमेंट ब्रांच में मर्ज किए जाने चाहिए. उदाहरण के लिए, अगर
android12-5.10-2022-09
के रिज़ॉल्यूशन के लिए पैच की ज़रूरत है, तो इसे पहले सेandroid12-5.10
में मर्ज किया जाना चाहिए.आपको जीकेआई की डेवलपमेंट ब्रांच से पैच चुनने होंगे और पैच को हर महीने की रिलीज़ ब्रांच में अपलोड करना होगा.
रिस्पॉन्स के अनुरोध में, आपको अनुरोध को प्राथमिकता (ज़रूरी) असाइन करनी होगी. इस प्राथमिकता से जीकेआई टीम को समय पर पार्टनर की बेहतर तरीके से मदद करने में मदद मिलती है. ज़रूरी या समय के हिसाब से संवेदनशील अनुरोधों के लिए, प्राथमिकता को P0 के तौर पर मार्क करें. P0 और P1 अनुरोधों के लिए, आपको यह भी बताना होगा कि बहुत कम समय के लिए वाकई ऐसा करना क्यों ज़रूरी है. नीचे दी गई टेबल में, गड़बड़ी की प्राथमिकता और उसे ठीक करने में लगने वाले समय (ईएसआरटी) को मैप किया गया है:
प्राथमिकता ईएसआरटी P0 2 कारोबारी दिन P1 5 कामकाजी दिन P2 10 कामकाजी दिन P3 15 कार्यदिवस
आपको हर रिलीज़ ब्रांच के लिए, अलग से रिस्पॉन्स देने का अनुरोध सबमिट करना होगा. उदाहरण के लिए, अगर
android12-5.10-2022-08
औरandroid12-5.10-2022-09
, दोनों के लिए रीस्पिन की ज़रूरत है, तो आपको दो रीस्पिन अनुरोध करने होंगे.बिल्ड उपलब्ध कराने और रेस्पिन करने के अनुरोध को 'ठीक की गई' के तौर पर मार्क करने के बाद, आपको अतिरिक्त सीएल जोड़ने के लिए फिर से अनुरोध नहीं करना चाहिए. अगर कुछ और पैच हैं जिन्हें मर्ज करने की ज़रूरत है, तो आपको एक नया रेस्पिन अनुरोध सबमिट करना होगा.
जिन सीएल पर विचार किया जा रहा है उन सभी के लिए, नीचे दिए गए टैग जोड़ें. रिस्पॉन्स के अनुरोध पर हुई प्रोग्रेस को इस जानकारी के बिना ब्लॉक कर दिया जाता है.
Bug
: हर CL के लिए तय किए गए मैसेज में गड़बड़ी का आईडी जोड़ना ज़रूरी है.Change-Id
: यह बेस ब्रांच में होने वाले बदलाव के चेंज-आईडी के जैसा ही होना चाहिए.
अगर जवाब देने के अनुरोध का जवाब देना ज़रूरी है और आपने तीन कामकाजी दिनों में जवाब नहीं दिया, तो प्राथमिकता को एक लेवल से डाउनग्रेड कर दिया जाएगा. उदाहरण के लिए, P0 को डाउनग्रेड करके P1 कर दिया जाएगा. अगर दो हफ़्ते तक कोई जवाब नहीं दिया जाता, तो गड़बड़ी को ठीक नहीं किया गया (पुराना) के तौर पर मार्क कर दिया जाता है.
रिस्पॉन्स का अनुरोध सबमिट करें
नीचे दिए गए डायग्राम में, रीस्पिन करने की प्रोसेस को दिखाया गया है. यह प्रोसेस तब शुरू होती है, जब OEM पार्टनर (आप) रिस्पॉन्स का अनुरोध सबमिट करता है.
दूसरी इमेज. रेसिन प्रोसेस
रिज़ॉल्यूशन की प्रोसेस में शामिल होने के लिए:
- GKI Respin अनुरोध फ़ॉर्म भरें.
और अपने Google तकनीकी खाता मैनेजर से तुरंत संपर्क करें. इस फ़ॉर्म से,
जीकेआई रेस्पिन के अनुरोध से जुड़ी गड़बड़ी बनती है. अनुरोध के रिस्पॉन्स से जुड़ी गड़बड़ियां, आपको (अनुरोध करने वाले व्यक्ति), जीकेआई टीम, और उन खास लोगों को दिखती हैं जिन्हें आपने गड़बड़ी की कॉपी सूची में जोड़ा है.
- अगर आपने पहले ही समस्या को ठीक कर लिया है, तो अनुरोध एओएसपी में पैच सबमिटल से किया जाना चाहिए, ताकि Google इसकी समीक्षा कर सके. अगर पैच सबमिट नहीं किया जा सकता, तो पैच को अनुरोध के साथ टेक्स्ट फ़ाइल के तौर पर अटैच करना होगा.
- अगर आपके पास कोई समाधान नहीं है, तो अनुरोध में कर्नेल वर्शन संख्या और लॉग जैसी ज़्यादा से ज़्यादा जानकारी होनी चाहिए, ताकि Google समस्या को डीबग करने में मदद कर सके.
- Google GKI टीम अनुरोध की समीक्षा करती है और उसे मंज़ूरी देती है. इसके अलावा, ज़्यादा जानकारी की ज़रूरत होने पर, वह आपको वापस असाइन करती है.
- समस्या ठीक करने के बाद, Google GKI टीम कोड उस बदलाव की समीक्षा (CR+2) करता है. समीक्षा, ईएसआरटी समयसीमा से शुरू होती है. जीकेआई की टीम रिग्रेशन के लिए चीज़ें मर्ज करती है, बनाती है, टेस्ट करती है, और बदलाव को प्रमाणित करती है.
- बाइनरी को ci.android.com पर रिलीज़ कर दिया गया है. ईएसआरटी समयसीमा खत्म हो जाती है और Google जीकेआई टीम अनुरोध को 'ठीक की गई' के तौर पर मार्क कर देती है और रिस्पॉन्स बिल्ड के बारे में बताती है. रेज़पिन बिल्ड को जेनेरिक कर्नेल इमेज (जीकेआई) रिलीज़ बिल्ड पेज पर भी पोस्ट किया जाता है.
GKE (जीकेआई) से जुड़ी योग्यताएं
जीकेआई बिल्ड के टाइप | क्वालिटी को लागू करने का तरीका | Notes |
---|---|---|
हर हफ़्ते | कटलफ़िश की जांच
|
|
हर महीने (सर्टिफ़ाइड) | कटलफ़िश की जांच
|
|
रिस्पॉन्स (सर्टिफ़ाइड) | कटलफ़िश की जांच
|
|
बिल्ड आर्टफ़ैक्ट कहां से डाउनलोड किए जा सकते हैं
सभी रिलीज़ के आर्टफ़ैक्ट ci.android.com से लिए जा सकते हैं.
आपको सीआई के बारे में ज़्यादा जानकारी मिल सकती है. इसमें Android लगातार इंटिग्रेशन डैशबोर्ड पर जांच के नतीजे भी शामिल हैं.
अक्सर पूछे जाने वाले सवाल
क्या पहले से रिलीज़ हो चुके जीकेआई के आधार पर नई जीकेआई बाइनरी बनाना मुमकिन है?
हां, इसे रिस्पिन कहा जाता है. रेस्पिन वाली प्रोसेस तब तक काम करती है, जब तक रिलीज़ किए गए जीकेआई बिल्ड (जिस पर रेस्पिन का अनुरोध किया जाता है) 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 आर्टफ़ैक्ट की कॉपी वापस पा सकते हैं.
क्या जीकेआई बाइनरी (इसमें इमरजेंसी स्पिन पैच भी शामिल है) सबसे नए कोड बेस पर बनाया गया है?
नहीं. रेस्पिन में सिर्फ़ वे पैच शामिल होते हैं जो चुने गए हर महीने प्रमाणित किए गए कर्नेल के ऊपर होते हैं. इन रिस्पॉन्स में, लॉन्च को ब्लॉक करने वाली सभी गड़बड़ियां ठीक कर दी गई हैं. ये गड़बड़ियां, किसी तय समय तक ओईएम की ओर से रिपोर्ट में शामिल कर ली जाती हैं. इसके लिए, महीने के हिसाब से रिलीज़ के बुनियादी वर्शन का इस्तेमाल किया जाता है. इस तरह की स्थिति का उदाहरण नीचे दिया गया है.
- OEM1 और OEM2 ने नवंबर 2021 से, GKI बाइनरी रिलीज़ का इस्तेमाल करने का फ़ैसला किया है.
- OEM1 और OEM2 को ऐसी समस्याओं का पता चलता है जिन्हें इस्तेमाल करने के लिए, पैच की ज़रूरत होती है. ये पैच अलग-अलग हो सकते हैं या एक जैसे हो सकते हैं.
- नवंबर 2021 की बाइनरी से जुड़े रिस्पॉन्स में, लॉन्च को ब्लॉक करने से जुड़ी समस्याएं ठीक की गई हैं. ये सुधार OEM1 और OEM2, दोनों ने रीस्पिन विंडो के दौरान बताए हैं. हालांकि, इनमें और कोई बदलाव नहीं किया गया है.
- दूसरे बुलेट पॉइंट में बताई गई समस्याओं को जीकेआई के हर महीने की रिलीज़ में भी शामिल किया गया है.
अक्टूबर respin में सभी OEM सबमिट किए गए पैच हैं, लेकिन अन्य OEM पैच हमें प्रभावित करते हैं, क्योंकि उनका हमारे प्रॉडक्ट के साथ विशिष्ट रूप से परीक्षण नहीं किया गया है. क्या सिर्फ़ हमारे पैच को शामिल किया जा सकता है?
ऐसा नहीं किया जा सकता. फ़िलहाल, "हर OEM" के रेस्पिन पाथ का साइज़ बढ़ाया नहीं जा सकता. इसके बजाय, GKI की टीम रेसिन बिल्ड में होने वाले हर बदलाव की जांच करती है. साथ ही, कोई नया बिल्ड बनाने से पहले, सभी उपलब्ध हार्डवेयर की मदद से इन बदलावों की जांच करती है. अगर GKI टीम को पता चलता है कि यह समस्या खास तौर पर किसी OEM/डिवाइस/मॉडल में है, तो जीकेआई टीम यह पक्का कर सकती है कि इस बदलाव से जोड़ा गया कोड सिर्फ़ उस डिवाइस/मॉडल/SKU पर काम करेगा जिस पर असर हुआ है.
यूनिफ़ाइड रिस्पॉन्स का सबसे बड़ा फ़ायदा यह है कि एक जैसे रिलीज़ बेस का इस्तेमाल करने वाले सभी डिवाइसों को एक-दूसरे से फ़ायदा मिलता है. खास तौर पर तब, जब उन्हें जिन गड़बड़ियों का पता चलता है वे जेनरिक होते हैं और वे सभी उपयोगकर्ताओं के लिए लागू होते हैं. कैरियर की जांच में मिले कोर कर्नेल बग इस कॉन्सेप्ट का एक खास उदाहरण है.
क्या कोई ऐसी स्थिति है जिसमें Google OEM पैच के बारे में खास जानकारी देता है और किसी समस्या की जानकारी देता है, ताकि OEM अपने प्रॉडक्ट के साथ पैच इस्तेमाल करने के असर और जोखिम का आकलन कर सकें?
Google तब तक रिस्पॉन्स में बदलाव नहीं करेगा, जब तक समस्या की पहचान नहीं हो जाती और सारी जानकारी इकट्ठा नहीं हो जाती. यह चेंजलॉग में दिखता है (मैसेज लिखें). Google, इस बात की जानकारी नहीं देता कि किस डिवाइस पर इसका असर पड़ेगा. हालांकि, OEMs को बदलाव लॉग में समस्या की जानकारी और समाधान हमेशा मिल सकता है.