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

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

दूसरी इमेज. रेसिन प्रोसेस

रिज़ॉल्यूशन की प्रोसेस में शामिल होने के लिए:

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

GKE (जीकेआई) से जुड़ी योग्यताएं

जीकेआई बिल्ड के टाइप	क्वालिटी को लागू करने का तरीका	Notes
हर हफ़्ते	कटलफ़िश की जांच चालू करें वीटीएस का सबसेट सीटीएस का सबसेट	सर्टिफ़ाइड नहीं है. सिर्फ़ टेस्टिंग के लिए और डिवाइस को फ़ेच किया जाता है. डिवाइस लॉन्च करने के लिए इस्तेमाल नहीं किया जा सकता.
हर महीने (सर्टिफ़ाइड)	कटलफ़िश की जांच चालू करें वीटीएस सीटीएस रेफ़रंस हार्डवेयर टेस्टिंग चालू करें वीटीएस सीटीएस
रिस्पॉन्स (सर्टिफ़ाइड)	कटलफ़िश की जांच चालू करें वीटीएस सीटीएस का सबसेट रेफ़रंस डिवाइस की जांच चालू करें वीटीएस	इसे GKI (जीकेआई) प्रमाणित बिल्ड के आधार पर बनाया गया है. बिल्ड को मंज़ूरी मिलने के बाद, उसे सर्टिफ़िकेट मिल जाता है.

बिल्ड आर्टफ़ैक्ट कहां से डाउनलोड किए जा सकते हैं

सभी रिलीज़ के आर्टफ़ैक्ट 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 को बदलाव लॉग में समस्या की जानकारी और समाधान हमेशा मिल सकता है.