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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आईडी बदलें

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

UID

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

राज्य

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

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

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

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

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

adb shell dumpsys platform_compat

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

आईडी बदलें

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

नाम

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

targetSDKVersion की ज़रूरी शर्तें

वह targetSDKVersion जिसके हिसाब से बदलाव गेट किया गया है. अगर कोई है, तो.

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

पैकेज ओवरराइड

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

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

packageOverrides={com.my.package=false}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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