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

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

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

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

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

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

पहली इमेज. डेवलपर के लिए सेटिंग और टूल में मौजूद, 'ऐप्लिकेशन के साथ काम करने के लिए किए गए बदलाव’ वाली स्क्रीन पर.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्टेट इनमें से कोई एक वैल्यू हो सकती है:

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

बदलावों को टॉगल करके बंद करने की सुविधा कब इस्तेमाल करें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

बदलावों को चालू या बंद करना

कंपैटिबिलिटी फ़्रेमवर्क की मदद से, डेवलपर के लिए सेटिंग और टूल या 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 या डेवलपर विकल्पों का इस्तेमाल करके सेट किया गया कोई भी ओवरराइड हट जाएगा:

adb shell am compat reset (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME

बदलावों को टॉगल करने से जुड़ी पाबंदियां

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

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

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