कंपैटिबिलिटी फ़्रेमवर्क टूल

Android 11 में, Android प्लैटफ़ॉर्म के नए वर्शन में व्यवहार में हुए बदलावों के हिसाब से, अपने ऐप्लिकेशन की जांच करने और उसे डीबग करने के लिए, नए डेवलपर टूल जोड़े गए हैं. ये टूल, काम करने के तरीके से जुड़े फ़्रेमवर्क का हिस्सा हैं. इनकी मदद से, ऐप्लिकेशन डेवलपर डेवलपर के विकल्पों या ADB का इस्तेमाल करके, काम करने के तरीके में होने वाले बदलावों को अलग-अलग चालू और बंद कर सकते हैं. API के सबसे नए और स्थिर वर्शन को टारगेट करने और Android के अगले वर्शन की झलक वाली रिलीज़ के साथ अपने ऐप्लिकेशन की जांच करने के लिए, इस सुविधा का इस्तेमाल करें.

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

यह कैसे पता लगाएं कि कौनसे बदलाव चालू हैं

ऐप्लिकेशन के व्यवहार में बदलाव करने की सुविधा चालू होने पर, इस बात पर असर पड़ सकता है कि आपका ऐप्लिकेशन उन प्लैटफ़ॉर्म एपीआई को कैसे ऐक्सेस करता है जिन पर इस बदलाव का असर पड़ता है. डेवलपर के विकल्पों, logcat या ADB निर्देशों का इस्तेमाल करके, यह देखा जा सकता है कि व्यवहार में कौनसे बदलाव चालू हैं.

'डेवलपर के लिए सेटिंग और टूल' का इस्तेमाल करके, चालू किए गए बदलावों की पहचान करना

आपके पास यह देखने का विकल्प होता है कि कौनसे बदलाव चालू हैं. साथ ही, डिवाइस के डेवलपर के विकल्पों में जाकर, उन बदलावों को चालू या बंद किया जा सकता है. इन विकल्पों को ऐक्सेस करने के लिए, यह तरीका अपनाएं:

1. अगर डेवलपर के लिए सेटिंग और टूल पहले से चालू नहीं हैं, तो उन्हें चालू करें.
2. अपने डिवाइस का सेटिंग ऐप्लिकेशन खोलें और सिस्टम > बेहतर > डेवलपर के लिए सेटिंग और टूल > ऐप्लिकेशन के साथ काम करने की सुविधा में हुए बदलाव पर जाएं.

3. सूची में से अपना ऐप्लिकेशन चुनें.

आम तौर पर, उपयोगकर्ता के व्यवहार में होने वाला हर बदलाव, इनमें से किसी एक कैटगरी में आता है:

• ऐसे बदलाव जिनका असर Android के उस वर्शन पर चलने वाले सभी ऐप्लिकेशन पर पड़ता है. भले ही, ऐप्लिकेशन का targetSdkVersion कुछ भी हो.

  ये बदलाव, कम्पैटिबिलिटी फ़्रेमवर्क में डिफ़ॉल्ट रूप से चालू होते हैं. साथ ही, ये यूज़र इंटरफ़ेस (यूआई) में डिफ़ॉल्ट रूप से चालू बदलाव सेक्शन में दिखते हैं.

• ऐसे बदलाव जिनका असर सिर्फ़ उन ऐप्लिकेशन पर पड़ता है जो Android के कुछ वर्शन को टारगेट करते हैं. इन बदलावों का असर सिर्फ़ उन ऐप्लिकेशन पर पड़ता है जो Android के किसी खास वर्शन को टारगेट करते हैं. इसलिए, इन्हें targetSDKVersion के हिसाब से सीमित किए गए बदलाव भी कहा जाता है.

  अगर आपका ऐप्लिकेशन, सूची में दिए गए एपीआई वर्शन के बजाय किसी नए वर्शन को टारगेट कर रहा है, तो ये बदलाव कंपैटिबिलिटी फ़्रेमवर्क में डिफ़ॉल्ट रूप से चालू होते हैं. उदाहरण के लिए, Android 13 (एपीआई लेवल 33) में targetSDKVersion के ज़रिए, व्यवहार में हुए बदलाव को यूज़र इंटरफ़ेस (यूआई) में targetSdkVersion >=33 के लिए चालू है सेक्शन में दिखाया जाएगा. Android के कुछ पुराने वर्शन में, इस सेक्शन का शीर्षक "SDK API_LEVEL के बाद चालू किया गया" होता है.

आपको पहली इमेज में डिफ़ॉल्ट रूप से बंद किए गए बदलाव नाम का एक सेक्शन भी दिखेगा. इस सेक्शन में शामिल बदलावों से कई काम किए जा सकते हैं. इन बदलावों को चालू करने से पहले, Android के उस वर्शन के लिए काम करने वाले फ़्रेमवर्क की सूची में जाकर, बदलाव के बारे में जानकारी पढ़ें.

logcat का इस्तेमाल करके, चालू किए गए बदलावों की पहचान करना

व्यवहार में होने वाले हर बदलाव के लिए, जब आपका ऐप्लिकेशन पहली बार उस एपीआई को कॉल करता है जिस पर असर पड़ा है, तो सिस्टम इस तरह का लॉगकैट मैसेज दिखाता है:

D CompatibilityChangeReporter: Compat change id reported: 194833441; UID 10265; state: ENABLED

हर logcat मैसेज में यह जानकारी शामिल होती है:

आईडी बदलना

इससे पता चलता है कि ऐप्लिकेशन पर किस बदलाव का असर पड़ रहा है. यह वैल्यू, ऐप्लिकेशन के साथ काम करने के तरीके में हुए बदलाव स्क्रीन पर बताए गए व्यवहार में हुए किसी एक बदलाव से मैप होती है (पहला चित्र देखें). इस उदाहरण में, 194833441, NOTIFICATION_PERM_CHANGE_ID पर मैप होता है.

यूआईडी

इससे पता चलता है कि बदलाव का असर किस ऐप्लिकेशन पर पड़ा है.

राज्य

इससे पता चलता है कि बदलाव का असर ऐप्लिकेशन पर पड़ रहा है या नहीं.

स्थिति इनमें से कोई एक हो सकती है:

राज्य	मतलब
ENABLED	यह बदलाव चालू हो गया है. अगर ऐप्लिकेशन उन एपीआई का इस्तेमाल करता है जिनमें बदलाव किया गया है, तो इसका असर ऐप्लिकेशन के व्यवहार पर पड़ेगा.
DISABLED	यह बदलाव बंद कर दिया गया है. इससे ऐप्लिकेशन पर कोई असर नहीं पड़ेगा. ध्यान दें: अगर ऐप्लिकेशन का targetSDKVersion, ज़रूरी थ्रेशोल्ड से कम होने की वजह से यह बदलाव बंद है, तो ऐप्लिकेशन के किसी नए वर्शन को टारगेट करने के लिए, targetSDKVersion बढ़ाने पर यह बदलाव डिफ़ॉल्ट रूप से चालू हो जाएगा.
LOGGED	बदलाव को, काम करने के तरीके के फ़्रेमवर्क के ज़रिए लॉग किया जा रहा है, लेकिन इसे चालू या बंद नहीं किया जा सकता. हालांकि, इस बदलाव को टॉगल नहीं किया जा सकता, लेकिन फिर भी इसका असर आपके ऐप्लिकेशन के काम करने के तरीके पर पड़ सकता है. ज़्यादा जानकारी के लिए, उस Android वर्शन के लिए, काम करने वाले फ़्रेमवर्क की सूची में बदलाव की जानकारी देखें. कई मामलों में, इस तरह के बदलाव प्रयोग के तौर पर किए जाते हैं और इन्हें अनदेखा किया जा सकता है.

ADB का इस्तेमाल करके, चालू किए गए बदलावों की पहचान करना

पूरे डिवाइस पर किए गए बदलावों (चालू और बंद, दोनों) का पूरा सेट देखने के लिए, यह ADB कमांड चलाएं:

adb shell dumpsys platform_compat

आउटपुट में, हर बदलाव के लिए यह जानकारी शामिल होती है:

आईडी बदलना

इस व्यवहार में हुए बदलाव के लिए यूनीक आइडेंटिफ़ायर. उदाहरण के लिए, 194833441.

नाम

इस बदलाव का नाम. उदाहरण के लिए, NOTIFICATION_PERM_CHANGE_ID.

targetSDKVersion की शर्तें

बदलाव किस targetSDKVersion के हिसाब से लागू किया गया है (अगर कोई है).

उदाहरण के लिए, अगर यह बदलाव सिर्फ़ SDK टूल के वर्शन 33 या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए चालू है, तो enableAfterTargetSdk=32 आउटपुट होता है. अगर बदलाव को targetSDKVersion से कंट्रोल नहीं किया जाता है, तो enableAfterTargetSdk=0 आउटपुट होता है.

पैकेज में बदलाव करने की सुविधा

हर उस पैकेज का नाम जहां बदलाव की डिफ़ॉल्ट स्थिति (चालू या बंद) को बदल दिया गया है.

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

packageOverrides={com.my.package=false}

targetSDKVersion के हिसाब से बदलावों को डिफ़ॉल्ट रूप से चालू या बंद किया जा सकता है. इसलिए, पैकेज की सूची में true या false, दोनों के इंस्टेंस शामिल हो सकते हैं. यह इस बात पर निर्भर करता है कि उन ऐप्लिकेशन के targetSDKVersion क्या हैं. उदाहरण के लिए:

packageOverrides={com.my.package=true, com.another.package=false}

खास बदलावों के बारे में ज़्यादा जानें

Android के हर वर्शन के दस्तावेज़ में, काम करने के तरीके में हुए बदलावों की पूरी सूची शामिल होती है. ज़्यादा जानकारी के लिए, यहां दिए गए लिंक देखें. ये लिंक, Android के उस वर्शन के हिसाब से दिए गए हैं जिसके लिए आपको अपने ऐप्लिकेशन की जांच करनी है:

• Android 15 (एपीआई लेवल 35)
• Android 14 (एपीआई लेवल 34)
• Android 13 (एपीआई लेवल 33)
• Android 12 (एपीआई लेवल 31 और 32)
• Android 11 (एपीआई लेवल 30)

बदलावों को टॉगल करने का समय

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

बदलावों को कब टॉगल करके बंद करना है

बदलावों को कब टॉगल करना है, यह आम तौर पर इस बात पर निर्भर करता है कि targetSDKVersion ने बदलाव की जांच की है या नहीं.

सभी ऐप्लिकेशन के लिए चालू किए गए बदलाव

सभी ऐप्लिकेशन पर असर डालने वाले बदलाव, किसी खास प्लैटफ़ॉर्म वर्शन के लिए डिफ़ॉल्ट रूप से चालू होते हैं. भले ही, आपके ऐप्लिकेशन का targetSDKVersion कुछ भी हो. इससे यह देखा जा सकता है कि उस प्लैटफ़ॉर्म वर्शन पर ऐप्लिकेशन चलाने से, आपके ऐप्लिकेशन पर असर पड़ा है या नहीं.

उदाहरण के लिए, अगर आपको Android 15 (एपीआई लेवल 35) को टारगेट करना है, तो सबसे पहले Android 15 वाले डिवाइस पर अपना ऐप्लिकेशन इंस्टॉल करें. इसके बाद, अपने सामान्य टेस्टिंग वर्कफ़्लो का इस्तेमाल करके, ऐप्लिकेशन की जांच करें. अगर आपके ऐप्लिकेशन में समस्याएं आ रही हैं, तो उस बदलाव को बंद करें जिसकी वजह से समस्या आ रही है. इससे, आपको अन्य समस्याओं की जांच जारी रखने में मदद मिलेगी.

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

आपको इन बदलावों की जांच को भी प्राथमिकता देनी चाहिए, क्योंकि Android के सार्वजनिक रिलीज़ बिल्ड का इस्तेमाल करते समय, इन बदलावों को टॉगल करके बंद नहीं किया जा सकता. आम तौर पर, आपको Android के हर वर्शन के लिए, जब वह वर्शन झलक के तौर पर उपलब्ध हो, तब इन बदलावों की जांच करनी चाहिए.

targetSDKVersion के हिसाब से किए गए बदलाव

अगर आपका ऐप्लिकेशन किसी खास targetSDKVersion को टारगेट कर रहा है, तो उस वर्शन के लिए किए गए बदलाव डिफ़ॉल्ट रूप से चालू होते हैं. इसलिए, अपने ऐप्लिकेशन के targetSDKVersion को नए वर्शन पर स्विच करने पर, आपके ऐप्लिकेशन पर एक साथ कई नए बदलावों का असर पड़ेगा.

इनमें से एक से ज़्यादा बदलावों का आपके ऐप्लिकेशन पर असर पड़ सकता है. इसलिए, ऐप्लिकेशन की जांच और डीबग करने के दौरान, आपको इनमें से कुछ बदलावों को अलग-अलग टॉगल करके बंद करना पड़ सकता है.

बदलावों को कब टॉगल करना है

जब कोई ऐप्लिकेशन, गेट किए गए वर्शन से पहले के SDK टूल के वर्शन को टारगेट करता है, तो किसी खास targetSDKVersion के हिसाब से किए गए बदलाव डिफ़ॉल्ट रूप से बंद हो जाते हैं. आम तौर पर, किसी नए targetSdkVersion को टारगेट करने के लिए, आपको ऐप्लिकेशन के व्यवहार में हुए बदलावों की सूची मिलेगी. आपको अपने ऐप्लिकेशन की जांच करनी होगी और उसमें गड़बड़ियों को ठीक करना होगा.

उदाहरण के लिए, हो सकता है कि अगले targetSdkVersion में, प्लैटफ़ॉर्म में होने वाले कई बदलावों के हिसाब से, अपने ऐप्लिकेशन की जांच की जा रही हो. डेवलपर के विकल्पों या ADB कमांड का इस्तेमाल करके, ऐप्लिकेशन मेनिफ़ेस्ट में बदलाव करने और एक साथ हर बदलाव के लिए ऑप्ट-इन करने के बजाय, आपके पास एक-एक करके हर बदलाव को चालू करने और उसकी जांच करने का विकल्प होता है. इस अतिरिक्त कंट्रोल की मदद से, बदलावों को अलग-अलग टेस्ट किया जा सकता है. साथ ही, एक साथ अपने ऐप्लिकेशन के कई हिस्सों को डीबग करने और अपडेट करने से बचा जा सकता है.

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

बदलावों को टॉगल करके चालू या बंद करना

साथ काम करने की सुविधा वाले फ़्रेमवर्क की मदद से, डेवलपर के विकल्पों या ADB निर्देशों का इस्तेमाल करके, हर बदलाव को टॉगल करके चालू या बंद किया जा सकता है. बदलावों को चालू या बंद करने से, आपका ऐप्लिकेशन क्रैश हो सकता है या सुरक्षा से जुड़े अहम बदलाव बंद हो सकते हैं. इसलिए, बदलावों को टॉगल करने के समय पर कुछ पाबंदियां हैं.

डेवलपर के लिए सेटिंग और टूल का इस्तेमाल करके, बदलावों को टॉगल करना

बदलावों को चालू या बंद करने के लिए, डेवलपर के विकल्पों का इस्तेमाल करें. डेवलपर के विकल्पों को ढूंढने के लिए, यह तरीका अपनाएं:

1. अगर डेवलपर के लिए सेटिंग और टूल पहले से चालू नहीं हैं, तो उन्हें चालू करें.
2. अपने डिवाइस का सेटिंग ऐप्लिकेशन खोलें और सिस्टम > बेहतर > डेवलपर के लिए सेटिंग और टूल > ऐप्लिकेशन के साथ काम करने की सुविधा में हुए बदलाव पर जाएं.
3. सूची में से अपना ऐप्लिकेशन चुनें.

4. बदलावों की सूची में, वह बदलाव ढूंढें जिसे आपको चालू या बंद करना है और स्विच पर टैप करें.

   

ADB का इस्तेमाल करके बदलावों को टॉगल करना

ADB का इस्तेमाल करके, किसी बदलाव को चालू या बंद करने के लिए, इनमें से कोई एक कमांड चलाएं:

adb shell am compat enable (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME
adb shell am compat disable (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME

CHANGE_ID (उदाहरण के लिए, 194833441) या CHANGE_NAME (उदाहरण के लिए, NOTIFICATION_PERM_CHANGE_ID) और अपने ऐप्लिकेशन का PACKAGE_NAME पास करें.

किसी बदलाव को डिफ़ॉल्ट स्थिति पर रीसेट करने के लिए, इस निर्देश का इस्तेमाल भी किया जा सकता है. इससे, एडीबी या डेवलपर के विकल्पों का इस्तेमाल करके सेट किए गए किसी भी बदलाव को हटाया जा सकता है:

adb shell am compat reset (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME

बदलावों को टॉगल करने पर पाबंदियां

डिफ़ॉल्ट रूप से, व्यवहार में होने वाला हर बदलाव चालू या बंद होता है. सभी ऐप्लिकेशन पर असर डालने वाले बदलाव, डिफ़ॉल्ट रूप से चालू होते हैं. अन्य बदलावों के लिए, targetSdkVersion की ज़रूरत होती है. जब कोई ऐप्लिकेशन, टारगेट किए गए SDK टूल के वर्शन या उससे नए वर्शन को टारगेट करता है, तो ये बदलाव डिफ़ॉल्ट रूप से चालू हो जाते हैं. वहीं, जब कोई ऐप्लिकेशन, टारगेट किए गए SDK टूल के वर्शन से पहले के वर्शन को टारगेट करता है, तो ये बदलाव डिफ़ॉल्ट रूप से बंद हो जाते हैं. किसी बदलाव को टॉगल करके चालू या बंद करने पर, उसकी डिफ़ॉल्ट स्थिति बदल जाती है.

कॉम्पैटिबिलिटी फ़्रेमवर्क का गलत इस्तेमाल होने से रोकने के लिए, बदलावों को टॉगल करने के समय पर कुछ पाबंदियां हैं. किसी बदलाव को टॉगल किया जा सकता है या नहीं, यह इस बात पर निर्भर करता है कि बदलाव किस तरह का है, आपका ऐप्लिकेशन डीबग किया जा सकता है या नहीं, और आपके डिवाइस पर किस तरह का बिल्ड चल रहा है. नीचे दी गई टेबल में बताया गया है कि अलग-अलग तरह के बदलावों को कब टॉगल किया जा सकता है:

बिल्ड किस तरह का है	डीबग नहीं किया जा सकने वाला ऐप्लिकेशन	डीबग किया जा सकने वाला ऐप्लिकेशन
	सभी बदलाव	targetSDKVersion के हिसाब से किए गए बदलाव	अन्य सभी बदलाव
डेवलपर के लिए झलक या बीटा वर्शन	टॉगल नहीं किया जा सकता	टॉगल किया जा सकता है	टॉगल किया जा सकता है
सार्वजनिक उपयोगकर्ता बिल्ड	टॉगल नहीं किया जा सकता	टॉगल किया जा सकता है	टॉगल नहीं किया जा सकता