इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

इस पेज पर बताया गया है कि GKI (जीकेआई) कैसे रिलीज़ किया जाता है. इसमें हर हफ़्ते, हर महीने, और रिलीज़ के बाद की गतिविधियां शामिल होती हैं तुरंत रिलीज़ करने की ज़रूरत नहीं होती. इस दस्तावेज़ का मकसद, OEM को इस बारे में दिशा-निर्देश कि जीकेआई चुनने के लिए जगह क्या है और बैंड से बाहर निकलने की प्रक्रिया क्या है आपातकालीन समाधान. OEM, जीकेआई (GKI)) का भी इस्तेमाल कर सकते हैं डेवलपमेंट ताकि आप इस बारे में ज़्यादा जान सकें कि Android Kernel टीम के साथ काम करके वे कैसे काम कर सकते हैं, ताकि इस्तेमाल करके GKI कर्नेल का इस्तेमाल किया जा सकता है.

जीकेआई की रिलीज़ के बीच का डेटा

केएमआई की पाबंदी के बाद 'जीकेआई' को हर महीने के हिसाब से रिलीज़ किया जाता है.

Android 13, 14, और 15 जीकेआई रिलीज़

नीचे दी गई टेबल सिर्फ़ इन पर लागू होती है android13-5.10 android13-5.15 और android14-5.15. इस एलान में सितंबर 2024 की रिलीज़ की तारीखें देखें.

जीकेआई की ओर से हर महीने प्रमाणित किए जाने वाले बिल्ड	चेक इन करने की आखिरी तारीख	GKI (जीकेआई) प्रीलोड के लिए तैयार होने की तारीख	पुष्टि की गई?
नवंबर	11 नवंबर, 2024	27 नवंबर, 2024	हां
जनवरी	17 जनवरी, 2025	31 जनवरी, 2025	हां
फ़रवरी	14 फ़रवरी, 2025	28 फ़रवरी, 2025	हां

नीचे दी गई टेबल सिर्फ़ इन पर लागू होती है android14-6.1 और android15-6.6. इस एलान में सितंबर 2024 की रिलीज़ की तारीखें देखें.

जीकेआई की ओर से हर महीने प्रमाणित किए जाने वाले बिल्ड	चेक इन करने की आखिरी तारीख	GKI (जीकेआई) प्रीलोड के लिए तैयार होने की तारीख	पुष्टि की गई?
अक्टूबर	1 अक्टूबर, 2024	14 अक्टूबर, 2024	हां
नवंबर	1 नवंबर, 2024	15 नवंबर, 2024	हां
दिसंबर	2 दिसंबर, 2024	16 दिसंबर, 2024	हां
जनवरी	6 जनवरी, 2025	22 जनवरी, 2025	हां

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 का इस्तेमाल कर सकते हैं. OEM को इनके साथ लॉन्च किया जा सकता है: Gकेआई से सर्टिफ़ाइड बिल्ड तब ही बनाया जाता है, जब वे Android सिक्योरिटी बुलेटिन (एएसबी).

हर हफ़्ते होने वाले डेवलपमेंट की रिलीज़

रिलीज़ की जांच कटलफ़िश की मदद से की जाती है ताकि यह पक्का किया जा सके कि वे क्वालिटी के लिए तय किए गए मानकों के मुताबिक हैं.

जीकेआई बाइनरी, Android पर खुद मैनेज करने के लिए उपलब्ध हैं सीआई क्योंकि बदलावों को मर्ज किया जाता है. हर हफ़्ते के बिल्ड प्रमाणित नहीं किए जाएंगे. हालांकि, इनका इस्तेमाल इस तरह किया जा सकता है विकास और परीक्षण के लिए आधाररेखा. हर हफ़्ते के बिल्ड का इस्तेमाल इन कामों के लिए नहीं किया जा सकता असली उपयोगकर्ताओं के लिए प्रोडक्शन डिवाइस बनाया जाता है.

हर महीने सर्टिफ़ाइड रिलीज़

हर महीने के जीकेआई की रिलीज़ में टेस्ट किया गया एक 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 की एलटीएस (लंबे समय तक सहायता) की शर्तों का पालन नहीं करती.
रेस्पिन सिर्फ़ उन गड़बड़ियों को ठीक करने के लिए इस्तेमाल किए जा सकते हैं जिन्हें तुरंत ठीक करने, सिंबल की सूची को अपडेट करने या का इस्तेमाल करें.
हर महीने रिलीज़ होने वाली शाखा में शामिल होने वाले सभी पैच, GKI की मुख्य डेवलपमेंट शाखा में पहले से ही मर्ज होने चाहिए. उदाहरण के लिए, अगर android12-5.10-2022-09 का रिज़ॉल्यूशन, इसे पहले से ही इसमें मर्ज किया जाना चाहिए android12-5.10.
आपको जीकेआई की डेवलपमेंट ब्रांच से पैच चुनकर और पैच को हर महीने रिलीज़ करने वाली ब्रांच में अपलोड करें.

रिस्पॉन्स के अनुरोध में, आपको अनुरोध को प्राथमिकता (ज़रूरी) असाइन करनी होगी. इस प्राथमिकता से जीकेआई टीम को समय पर पार्टनर की बेहतर तरीके से मदद करने में मदद मिलती है. ज़रूरी या समय के हिसाब से संवेदनशील अनुरोधों के लिए, प्राथमिकता को P0 के तौर पर मार्क करें. P0 और P1 के लिए तो आपको यह भी बताना होगा कि यह ज़रूरी है या नहीं. नीचे दी गई टेबल में, गड़बड़ी की प्राथमिकता और उसे हल करने में लगने वाले समय (ईएसआरटी) की मैपिंग:

प्राथमिकता	ESRT
P0	2 व्यावसायिक दिन
P1	5 कामकाजी दिन
P2	10 कामकाजी दिन
P3	15 कार्यदिवस

आपको हर रिलीज़ ब्रांच के लिए, अलग से रिस्पॉन्स अनुरोध सबमिट करना होगा. उदाहरण के लिए, अगर android12-5.10-2022-08 और, दोनों के लिए रिस्पॉन्स की ज़रूरत है android12-5.10-2022-09, आपको दो बार रिस्पॉन्स के अनुरोध करने होंगे.
बिल्ड उपलब्ध कराने और रेस्पिन करने के अनुरोध को 'ठीक की गई' के तौर पर मार्क करने के बाद, आपको अतिरिक्त सीएल जोड़ने के लिए, रिस्पॉन्स में लगने वाला अनुरोध फिर से नहीं खोलना चाहिए. अगर ऐसे और पैच हैं जिन्हें मर्ज करना है, तो आपको फिर से अनुरोध सबमिट करना होगा.
जिन सीएल पर विचार किया जा रहा है उनके लिए, ये टैग जोड़ें.
- Bug: हर CL के लिए तय किए गए मैसेज में गड़बड़ी का आईडी जोड़ना ज़रूरी है.
- Change-Id: यह बेस ब्रांच में होने वाले बदलाव के चेंज-आईडी के जैसा ही होना चाहिए.
ध्यान दें: इन टैग के बिना, रिस्पॉन्स के अनुरोध की प्रोग्रेस को ब्लॉक कर दिया जाता है.
अगर रिस्पॉन्स के अनुरोध का जवाब देने की ज़रूरत है और आपने Google से जवाब नहीं दिया है, तीन कामकाजी दिनों के अंदर, प्राथमिकता एक लेवल से डाउनग्रेड हो जाती है (उदाहरण के लिए, P0 को डाउनग्रेड करके, P1 कर दिया गया है. अगर दो हफ़्ते तक कोई जवाब नहीं मिलता, तो ठीक नहीं किया गया (पुराना) के तौर पर मार्क किया गया है.

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

नीचे दिए गए डायग्राम में, रीस्पिन करने की प्रोसेस को दिखाया गया है. यह प्रोसेस तब शुरू होती है, जब OEM पार्टनर (आप) अनुरोध को फिर से सबमिट करने का अनुरोध करेगा.

आपातकालीन स्थिति में फिर से स्पिन करने की प्रोसेस दूसरी इमेज. रेसिन प्रोसेस

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

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

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

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

जीकेआई बिल्ड के टाइप

क्वालिटी को लागू करने का तरीका

Notes

हर हफ़्ते

कटलफ़िश की जांच

चालू करें
वीटीएस का सबसेट
सीटीएस का सबसेट

सर्टिफ़ाइड नहीं है. सिर्फ़ टेस्टिंग के लिए और
डिवाइस को फ़ेच किया जाता है.
डिवाइस लॉन्च करने के लिए इस्तेमाल नहीं किया जा सकता.

हर महीने (सर्टिफ़ाइड)

कटलफ़िश टेस्टिंग

चालू करें
वीटीएस
सीटीएस

रेफ़रंस हार्डवेयर की जांच

चालू करें
वीटीएस
सीटीएस

रिस्पॉन्स (सर्टिफ़ाइड)

कटलफ़िश की जांच

चालू करें
VTS
सीटीएस का सबसेट

रेफ़रंस डिवाइस की टेस्टिंग

चालू करें
वीटीएस

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

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

सभी रिलीज़ के आर्टफ़ैक्ट इनसे लिए जा सकते हैं ci.android.com पर जाकर खोज सकते हैं.

आपको सीआई के बारे में ज़्यादा जानकारी मिल सकती है. इसमें जांच के बारे में जानकारी भी शामिल है 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 की टीम को पता चलता है कि समस्या किसी OEM, डिवाइस या मॉडल, जीकेआई टीम यह पक्का कर सकती है कि बदलाव से जोड़ा गया कोड सिर्फ़ काम करता हो जिस डिवाइस, मॉडल या SKU पर असर पड़ा हो.

यूनिफ़ाइड रीस्पिन का सबसे बड़ा फ़ायदा यह है कि हर डिवाइस को एक-दूसरे से मिलने वाले एक जैसे फ़ायदों का इस्तेमाल करना. खास तौर पर, ऐसा तब होता है, जब ये बहुत आम होते हैं और सभी लोगों के लिए सही होते हैं. कोर कर्नेल गड़बड़ियों का पता चला का सटीक उदाहरण दिया गया है.

क्या ऐसी स्थितियां होती हैं जब Google, OEM पैच और समस्याओं के बारे में खास जानकारी देता है, ताकि OEM अपने प्रॉडक्ट में पैच लागू करने के असर और जोखिम का आकलन कर सकें?

जब तक समस्या ठीक नहीं होती, तब तक Google उससे मिले रिस्पॉन्स में कोई बदलाव नहीं करेगा और सारी जानकारी इकट्ठा कर ली गई है. यह बदलाव, बदलावों की सूची (कमिट मैसेज) में दिखता है. Google यह नहीं बताता कि उससे किस डिवाइस पर असर होगा. हालांकि, OEM, बदलाव लॉग में समस्या की जानकारी और समाधान कभी भी देख सकते हैं.