SDK टूल में उपलब्ध नहीं होने वाले इंटरफ़ेस पर पाबंदियां

Android 9 (एपीआई लेवल 28) से, प्लैटफ़ॉर्म यह तय करता है कि आपका ऐप्लिकेशन किन नॉन-एसडीके इंटरफ़ेस का इस्तेमाल कर सकता है. ये पाबंदियां तब लागू होती हैं, जब कोई ऐप्लिकेशन, SDK टूल में उपलब्ध नहीं होने वाले इंटरफ़ेस का रेफ़रंस देता है या रिफ़्लेक्शन या JNI का इस्तेमाल करके उसका हैंडल पाने की कोशिश करता है. ये पाबंदियां इसलिए लगाई गई हैं, ताकि उपयोगकर्ता और डेवलपर के अनुभव को बेहतर बनाया जा सके. साथ ही, उपयोगकर्ताओं के लिए क्रैश होने के जोखिम और डेवलपर के लिए इमरजेंसी रोलआउट के जोखिम को कम किया जा सके. इस फ़ैसले के बारे में ज़्यादा जानने के लिए, गैर-एसडीके इंटरफ़ेस का इस्तेमाल कम करके, ऐप्लिकेशन को ज़्यादा भरोसेमंद बनाना लेख पढ़ें.

एसडीके और गैर-एसडीके इंटरफ़ेस के बीच अंतर बताना

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

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

बिना एसडीके वाले एपीआई की सूचियां

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

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

सूची में देखें कोड टैग ब्यौरा
ब्लॉकलिस्ट
  • blocked
  • बंद कर दिया गया: blacklist
 ऐसे नॉन-एसडीके इंटरफ़ेस जिनका इस्तेमाल नहीं किया जा सकता. भले ही, आपके ऐप्लिकेशन का टारगेट एपीआई लेवल कुछ भी हो. अगर आपका ऐप्लिकेशन इनमें से किसी इंटरफ़ेस को ऐक्सेस करने की कोशिश करता है, तो सिस्टम गड़बड़ी की सूचना देता है.
कुछ शर्तों के साथ ब्लॉक किया गया
  • max-target-x
  • बंद कर दिया गया: greylist-max-x

Android 9 (एपीआई लेवल 28) से, हर एपीआई लेवल में नॉन-एसडीके इंटरफ़ेस होते हैं. जब कोई ऐप्लिकेशन उस एपीआई लेवल को टारगेट करता है, तो इन इंटरफ़ेस पर पाबंदी लग जाती है.

इन सूचियों को, ज़्यादा से ज़्यादा एपीआई लेवल (max-target-x) के हिसाब से लेबल किया गया है. इससे यह पता चलता है कि कोई ऐप्लिकेशन, इस लेवल तक टारगेट कर सकता है. इसके बाद, वह ऐप्लिकेशन उस सूची में मौजूद नॉन-एसडीके इंटरफ़ेस को ऐक्सेस नहीं कर पाएगा. उदाहरण के लिए, Android Pie में ब्लॉक नहीं किया गया कोई नॉन-एसडीके इंटरफ़ेस, अब Android 10 में ब्लॉक कर दिया गया है. यह max-target-p (greylist-max-p) सूची का हिस्सा है. यहां "p" का मतलब Pie या Android 9 (एपीआई लेवल 28) है.

अगर आपका ऐप्लिकेशन, टारगेट एपीआई लेवल के लिए प्रतिबंधित इंटरफ़ेस को ऐक्सेस करने की कोशिश करता है, तो सिस्टम ऐसे काम करता है जैसे एपीआई, ब्लॉक की गई सूची का हिस्सा हो.
काम नहीं करता
  • unsupported
  • बंद कर दिया गया: greylist
 ऐसे गैर-एसडीके इंटरफ़ेस जिनका इस्तेमाल करने पर कोई पाबंदी नहीं है और आपका ऐप्लिकेशन उनका इस्तेमाल कर सकता है. हालांकि, ध्यान दें कि इन इंटरफ़ेस के लिए सहायता उपलब्ध नहीं है और इनमें बिना किसी सूचना के बदलाव किया जा सकता है. Android के आने वाले वर्शन में, इन इंटरफ़ेस को max-target-x सूची में शामिल किया जा सकता है. इसके बाद, इन्हें कुछ शर्तों के साथ ब्लॉक किया जा सकता है.
SDK टूल
  • public-api और sdk, दोनों
  • बंद कर दिया गया: public-api और whitelist, दोनों
 ऐसे इंटरफ़ेस जिनका इस्तेमाल बिना किसी शुल्क के किया जा सकता है. साथ ही, अब इन्हें आधिकारिक तौर पर दस्तावेज़ में शामिल Android फ़्रेमवर्क पैकेज इंडेक्स के हिस्से के तौर पर इस्तेमाल किया जा सकता है.
टेस्ट एपीआई
  • test-api
 ऐसे इंटरफ़ेस जिनका इस्तेमाल सिस्टम की अंदरूनी जांच के लिए किया जाता है. जैसे, ऐसे एपीआई जो Compatibility Test Suite (CTS) के ज़रिए जांच करने में मदद करते हैं. टेस्ट एपीआई, एसडीके का हिस्सा नहीं हैं. Android 11 (एपीआई लेवल 30) से, टेस्ट एपीआई को ब्लॉक की गई सूची में शामिल किया गया है. इसलिए, ऐप्लिकेशन को इनका इस्तेमाल करने की अनुमति नहीं है. भले ही, उनका टारगेट एपीआई लेवल कुछ भी हो. सभी टेस्ट एपीआई काम नहीं करते हैं. साथ ही, बिना किसी सूचना के इनमें बदलाव किया जा सकता है. भले ही, प्लैटफ़ॉर्म का एपीआई लेवल कुछ भी हो.

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

यह पता लगाना कि कोई इंटरफ़ेस किस सूची से जुड़ा है

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

Android 16

Android 16 (एपीआई लेवल 36) के लिए, यहां दी गई फ़ाइल डाउनलोड की जा सकती है. इसमें सभी नॉन-एसडीके इंटरफ़ेस और उनकी सूचियों के बारे में बताया गया है:

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: 9102af02fe6ab68b92464bdff5e5b09f3bd62c65d1130aaf85d3296f17d38074

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

Android 15

Android 15 (एपीआई लेवल 35) के लिए, यहां दी गई फ़ाइल डाउनलोड की जा सकती है. इसमें सभी नॉन-एसडीके इंटरफ़ेस और उनकी सूचियों के बारे में बताया गया है:

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: 40134e205e58922a708c453726b279a296e6a1f34a988abd90cec0f3432ea5a9

Android 15 में, बिना एसडीके वाले एपीआई की सूची में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 15 में, बिना एसडीके वाले इंटरफ़ेस पर पाबंदियों से जुड़े अपडेट लेख पढ़ें.

Android 14

Android 14 (एपीआई लेवल 34) के लिए, यहां दी गई फ़ाइल डाउनलोड की जा सकती है. इसमें सभी नॉन-एसडीके इंटरफ़ेस और उनसे जुड़ी सूचियों के बारे में बताया गया है:

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: 7e00db074cbe51c51ff4b411f7b48e98692951395c5c17d069c822cc1d0eae0f

Android 14 में, बिना एसडीके वाले एपीआई की सूची में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 14 में, बिना एसडीके वाले इंटरफ़ेस पर पाबंदियों से जुड़े अपडेट लेख पढ़ें.

Android 13

Android 13 (एपीआई लेवल 33) के लिए, यहां दी गई फ़ाइल डाउनलोड की जा सकती है. इसमें सभी नॉन-एसडीके इंटरफ़ेस और उनसे जुड़ी सूचियों के बारे में बताया गया है:

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: 233a277aa8ac475b6df61bffd95665d86aac6eb2ad187b90bf42a98f5f2a11a3

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

Android 12

Android 12 (एपीआई लेवल 31) के लिए, यहां दी गई फ़ाइल डाउनलोड की जा सकती है. इसमें सभी नॉन-एसडीके इंटरफ़ेस और उनसे जुड़ी सूचियों के बारे में बताया गया है:

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: 40674ff4291eb268f86561bf687e69dbd013df9ec9531a460404532a4ac9a761

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

Android 11

Android 11 (एपीआई लेवल 30) के लिए, यहां दी गई फ़ाइल डाउनलोड करें. इसमें, एसडीके टूल के बाहर के सभी इंटरफ़ेस और उनसे जुड़ी सूचियों के बारे में बताया गया है:

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: a19d839f4f61dc9c94960ae977b2e0f3eb30f880ba1ffe5108e790010b477a56

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

Android 10

Android 10 (एपीआई लेवल 29) के लिए, यहां दी गई फ़ाइल डाउनलोड की जा सकती है. इसमें सभी नॉन-एसडीके इंटरफ़ेस और उनसे जुड़ी सूचियों के बारे में बताया गया है:

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: f22a59c215e752777a114bd9b07b0b6b4aedfc8e49e6efca0f99681771c5bfeb

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

Android 9

Android 9 (एपीआई लेवल 28) के लिए, यहां दी गई टेक्स्ट फ़ाइल में उन नॉन-एसडीके एपीआई की सूची दी गई है जिन पर पाबंदी नहीं है (ग्रेलिस्ट किए गए): hiddenapi-light-greylist.txt.

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

AOSP से सूचियां जनरेट करना

AOSP के साथ काम करते समय, ऐसी hiddenapi-flags.csv फ़ाइल जनरेट की जा सकती है जिसमें सभी नॉन-एसडीके इंटरफ़ेस और उनकी सूचियां शामिल हों. इसके लिए, AOSP सोर्स कोड डाउनलोड करें. इसके बाद, यह कमांड चलाएं:

m out/soong/hiddenapi/hiddenapi-flags.csv

इसके बाद, आपको यह फ़ाइल यहां मिलेगी:

out/soong/hiddenapi/hiddenapi-flags.csv

गैर-एसडीके इंटरफ़ेस को ऐक्सेस करने पर, ऐप्लिकेशन के काम करने का तरीका

इस टेबल में बताया गया है कि अगर आपका ऐप्लिकेशन, ब्लॉक की गई सूची में शामिल किसी ऐसे इंटरफ़ेस को ऐक्सेस करने की कोशिश करता है जिसमें SDK टूल नहीं है, तो क्या होगा.

ऐक्सेस करने का तरीका नतीजा
किसी फ़ील्ड का रेफ़रंस देने वाला Dalvik निर्देश NoSuchFieldError थ्रो किया गया
किसी तरीके का रेफ़रंस देने वाला Dalvik निर्देश NoSuchMethodError थ्रो किया गया
Class.getDeclaredField() या Class.getField() का इस्तेमाल करके मनोदशा बताना NoSuchFieldException थ्रो किया गया
Class.getDeclaredMethod() और Class.getMethod() का इस्तेमाल करके रिफ़्लेक्शन NoSuchMethodException थ्रो किया गया
Class.getDeclaredFields() और Class.getFields() का इस्तेमाल करके रिफ़्लेक्शन नतीजों में, एसडीके इंटिग्रेट न करने वाले सदस्यों को शामिल नहीं किया गया है
Class.getDeclaredMethods() और Class.getMethods() का इस्तेमाल करके रिफ़्लेक्शन नतीजों में, एसडीके इंटिग्रेट न करने वाले सदस्यों को शामिल नहीं किया गया है
env->GetFieldID() का इस्तेमाल करके JNI NULL लौटाया गया, NoSuchFieldError फेंका गया
env->GetMethodID() का इस्तेमाल करके JNI NULL लौटाया गया, NoSuchMethodError फेंका गया

गैर-SDK इंटरफ़ेस के लिए अपने ऐप्लिकेशन की जांच करना

आपके पास अपने ऐप्लिकेशन में, गैर-एसडीके इंटरफ़ेस की जाँच करने के कई तरीके हैं.

डीबग किए जा सकने वाले ऐप्लिकेशन का इस्तेमाल करके जांच करना

गैर-एसडीके इंटरफ़ेस की जांच करने के लिए, Android 9 (एपीआई लेवल 28) या इससे बाद के वर्शन पर काम करने वाले डिवाइस या एम्युलेटर पर, डीबग किए जा सकने वाले ऐप्लिकेशन को बनाएं और चलाएं. पक्का करें कि आपके ऐप्लिकेशन का टारगेट एपीआई लेवल, आपके इस्तेमाल किए जा रहे डिवाइस या एम्युलेटर से मेल खाता हो.

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

  • डिक्लेयर करने वाली क्लास, नाम, और टाइप (Android रनटाइम में इस्तेमाल किए जाने वाले फ़ॉर्मैट में).
  • ऐक्सेस करने का तरीका: लिंक करना, रिफ़्लेक्शन का इस्तेमाल करना या JNI का इस्तेमाल करना.
  • यह जानकारी कि गैर-एसडीके इंटरफ़ेस किस सूची से जुड़ा है.

इन लॉग मैसेज को ऐक्सेस करने के लिए, adb logcat का इस्तेमाल किया जा सकता है. ये मैसेज, चल रहे ऐप्लिकेशन के पीआईडी के नीचे दिखते हैं. उदाहरण के लिए, लॉग में कोई एंट्री इस तरह दिख सकती है:

Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI)

StrictMode API का इस्तेमाल करके टेस्ट करना

StrictMode एपीआई का इस्तेमाल करके, ऐसे इंटरफ़ेस की भी जाँच की जा सकती है जिनमें SDK टूल नहीं है. इसे चालू करने के लिए, detectNonSdkApiUsage तरीके का इस्तेमाल करें. StrictMode एपीआई चालू करने के बाद, आपको ऐसे हर इंटरफ़ेस के इस्तेमाल के लिए कॉलबैक मिल सकता है जो एसडीके टूल में उपलब्ध नहीं है. इसके लिए, penaltyListener का इस्तेमाल करें. यहां कस्टम हैंडलिंग लागू की जा सकती है. कॉलबैक में दिया गया Violation ऑब्जेक्ट, Throwable से मिलता है. साथ ही, इसमें शामिल स्टैक ट्रेस से इस्तेमाल के बारे में जानकारी मिलती है.

Veridex टूल का इस्तेमाल करके जांच करना

अपने APK पर, Veridex के स्टैटिक विश्लेषण टूल को भी चलाया जा सकता है. Veridex टूल, APK के पूरे कोडबेस को स्कैन करता है. इसमें तीसरे पक्ष की लाइब्रेरी भी शामिल होती हैं. साथ ही, यह गैर-एसडीके इंटरफ़ेस के इस्तेमाल से जुड़ी किसी भी समस्या की रिपोर्ट करता है.

Veridex टूल की सीमाओं में ये शामिल हैं:

  • यह JNI के ज़रिए किए गए इनवोकेशन का पता नहीं लगा सकता.
  • यह रिफ़्लेक्शन के ज़रिए, सिर्फ़ कुछ इनवोकेशन का पता लगा सकता है.
  • इनऐक्टिव कोड पाथ के लिए, इसका विश्लेषण सिर्फ़ एपीआई लेवल की जांच तक सीमित है.
  • इसे सिर्फ़ उन मशीनों पर चलाया जा सकता है जो SSE4.2 और POPCNT निर्देशों के साथ काम करती हैं.

विंडो

Windows के लिए नेटिव बाइनरी उपलब्ध नहीं कराई जाती हैं. हालांकि, Windows पर veridex टूल को चलाया जा सकता है. इसके लिए, Windows Subsystem for Linux (WSL) का इस्तेमाल करके Linux बाइनरी को एक्ज़ीक्यूट करें. इस सेक्शन में दिया गया तरीका अपनाने से पहले, WSL इंस्टॉल करें और Linux डिस्ट्रिब्यूशन के तौर पर Ubuntu को चुनें.

Ubuntu इंस्टॉल करने के बाद, Ubuntu टर्मिनल लॉन्च करें. इसके बाद, यह तरीका अपनाएं:

  1. Android रनटाइम प्रीबिल्ट रिपॉज़िटरी से, veridex टूल डाउनलोड करें.
  2. appcompat.tar.gz फ़ाइल का कॉन्टेंट निकालें.
  3. एक्सट्रैक्ट किए गए फ़ोल्डर में, veridex-linux.zip फ़ाइल ढूंढें और उसे एक्सट्रैक्ट करें.

  4. अनज़िप किए गए फ़ोल्डर पर जाएं. इसके बाद, यह कमांड चलाएं. यहां your-app.apk वह APK है जिसकी आपको जांच करनी है:

    ./appcompat.sh --dex-file=your-app.apk

macOS

macOS पर veridex टूल चलाने के लिए, यह तरीका अपनाएं:

  1. Android रनटाइम प्रीबिल्ट रिपॉज़िटरी से, veridex टूल डाउनलोड करें.
  2. appcompat.tar.gz फ़ाइल का कॉन्टेंट निकालें.
  3. एक्सट्रैक्ट किए गए फ़ोल्डर में, veridex-mac.zip फ़ाइल ढूंढें और उसे एक्सट्रैक्ट करें.

  4. अनज़िप किए गए फ़ोल्डर पर जाएं. इसके बाद, यह निर्देश चलाएं. इसमें /path-from-root/your-app.apk उस APK का पाथ है जिसे आपको टेस्ट करना है. यह आपके सिस्टम की रूट डायरेक्ट्री से शुरू होता है:

    ./appcompat.sh --dex-file=/path-from-root/your-app.apk

Linux

Linux पर veridex टूल चलाने के लिए, यह तरीका अपनाएं:

  1. Android रनटाइम प्रीबिल्ट रिपॉज़िटरी से, veridex टूल डाउनलोड करें.
  2. appcompat.tar.gz फ़ाइल का कॉन्टेंट निकालें.
  3. एक्सट्रैक्ट किए गए फ़ोल्डर में, veridex-linux.zip फ़ाइल ढूंढें और उसे एक्सट्रैक्ट करें.

  4. अनज़िप किए गए फ़ोल्डर पर जाएं. इसके बाद, यह कमांड चलाएं. यहां your-app.apk वह APK है जिसकी आपको जांच करनी है:

    ./appcompat.sh --dex-file=your-app.apk

Android Studio के लिंट टूल का इस्तेमाल करके जांच करना

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

किसी प्रोजेक्ट, फ़ोल्डर या फ़ाइल पर, कमांड लाइन से लिंट टूल को चलाया जा सकता है. इसके अलावा, मैन्युअल तरीके से जांचें भी की जा सकती हैं.

Play Console का इस्तेमाल करके टेस्ट करना

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

ज़्यादा जानकारी के लिए, समस्याओं का पता लगाने के लिए, प्री-लॉन्च रिपोर्ट का इस्तेमाल करना में Android के साथ काम करने से जुड़ा सेक्शन देखें.

नए सार्वजनिक एपीआई का अनुरोध करना

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

सुविधा का अनुरोध करते समय, यह जानकारी दें:

  • उस एपीआई का नाम जो काम नहीं करता. साथ ही, Accessing hidden ... logcat मैसेज में दिखने वाला पूरा डिस्क्रिप्टर.
  • इन एपीआई का इस्तेमाल क्यों करना है. साथ ही, एपीआई के लिए ज़रूरी हाई-लेवल की सुविधा के बारे में जानकारी. सिर्फ़ लो लेवल की जानकारी नहीं.
  • आपके मकसद के लिए, सार्वजनिक एसडीके से जुड़े कोई भी एपीआई क्यों काफ़ी नहीं हैं.
  • आपने समस्या हल करने के लिए कोई और तरीका आज़माया है या नहीं. अगर आज़माया है, तो वह तरीका काम क्यों नहीं किया.

सुविधा के लिए अनुरोध करते समय यह जानकारी देने से, सार्वजनिक तौर पर उपलब्ध नया एपीआई मिलने की संभावना बढ़ जाती है.

अन्य सवाल

इस सेक्शन में, डेवलपर के अक्सर पूछे जाने वाले कुछ अन्य सवालों के जवाब दिए गए हैं:

सामान्य सवाल

Google यह कैसे पक्का कर सकता है कि इश्यूट्रैकर के ज़रिए, सभी ऐप्लिकेशन की ज़रूरतों को पूरा किया जा सकता है?

हमने Android 9 (एपीआई लेवल 28) के लिए शुरुआती सूचियां बनाई हैं. इसके लिए, ऐप्लिकेशन का स्टैटिक विश्लेषण किया गया था. इसमें इन तरीकों का इस्तेमाल किया गया था:

  • Play और नॉन-प्ले ऐप्लिकेशन की मैन्युअल टेस्टिंग
  • इंटरनल रिपोर्ट
  • इंटरनल उपयोगकर्ताओं से डेटा अपने-आप इकट्ठा होने की सुविधा
  • डेवलपर प्रीव्यू रिपोर्ट
  • ज़्यादा स्टैटिक विश्लेषण, जिसे इस तरह से डिज़ाइन किया गया था कि इसमें ज़्यादा फ़ॉल्स पॉज़िटिव शामिल किए जा सकें

हम हर नई रिलीज़ के लिए सूचियों का आकलन करते हैं. इसमें हम एपीआई के इस्तेमाल के साथ-साथ, समस्या ट्रैकर के ज़रिए डेवलपर से मिले सुझाव/राय/शिकायत को भी ध्यान में रखते हैं.

मैं गैर-एसडीके इंटरफ़ेस का ऐक्सेस कैसे चालू करूं?

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

Android 10 (एपीआई लेवल 29) या इसके बाद के वर्शन

ऐक्सेस चालू करने के लिए, यहां दिया गया adb कमांड इस्तेमाल करें

निर्देश:

adb shell settings put global hidden_api_policy  1

एपीआई लागू करने की नीति को डिफ़ॉल्ट सेटिंग पर रीसेट करने के लिए, इस कमांड का इस्तेमाल करें:

adb shell settings delete global hidden_api_policy
Android 9 (एपीआई लेवल 28)

ऐक्सेस चालू करने के लिए, इन adb कमांड का इस्तेमाल करें:

adb shell settings put global hidden_api_policy_pre_p_apps  1
adb shell settings put global hidden_api_policy_p_apps 1

एपीआई लागू करने की नीति को डिफ़ॉल्ट सेटिंग पर रीसेट करने के लिए, इन कमांड का इस्तेमाल करें:

adb shell settings delete global hidden_api_policy_pre_p_apps
adb shell settings delete global hidden_api_policy_p_apps

एपीआई लागू करने की नीति में पूर्णांक को इनमें से किसी एक वैल्यू पर सेट किया जा सकता है:

  • 0: गैर-SDK इंटरफ़ेस का पता लगाने की सभी सुविधाओं को बंद करें. इस सेटिंग का इस्तेमाल करने पर, SDK टूल के बाहर के इंटरफ़ेस के इस्तेमाल से जुड़े सभी लॉग मैसेज बंद हो जाते हैं. साथ ही, StrictMode API का इस्तेमाल करके अपने ऐप्लिकेशन की जांच नहीं की जा सकती. हम इस सेटिंग का इस्तेमाल करने का सुझाव नहीं देते.
  • 1: सभी गैर-एसडीके इंटरफ़ेस का ऐक्सेस चालू करें. हालांकि, गैर-एसडीके इंटरफ़ेस के इस्तेमाल से जुड़ी चेतावनियों के साथ लॉग मैसेज प्रिंट करें. इस सेटिंग का इस्तेमाल करके, StrictMode एपीआई का इस्तेमाल करके अपने ऐप्लिकेशन को टेस्ट किया जा सकता है.
  • 2: ब्लॉक की गई सूची में शामिल या टारगेट एपीआई लेवल के हिसाब से कुछ शर्तों के साथ ब्लॉक किए गए गैर-एसडीके इंटरफ़ेस के इस्तेमाल की अनुमति न दें.

ऐसे इंटरफ़ेस की सूचियों के बारे में सवाल जो एसडीके टूल में उपलब्ध नहीं हैं

मुझे सिस्टम इमेज में, एसडीके से बाहर के एपीआई की सूचियां कहां मिलेंगी?

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

क्या एक ही Android वर्शन वाले अलग-अलग ओईएम डिवाइसों पर, नॉन-एसडीके एपीआई की सूचियां एक जैसी होती हैं?

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

क्या नेटिव कोड में, नॉन-एनडीके इंटरफ़ेस के इस्तेमाल पर कोई पाबंदी है?

Android SDK टूल में Java इंटरफ़ेस शामिल होते हैं. इस प्लैटफ़ॉर्म ने Android 7 (एपीआई लेवल 26) में, नेटिव C/C++ कोड के लिए नॉन-एनडीके इंटरफ़ेस के ऐक्सेस को सीमित करना शुरू कर दिया था. ज़्यादा जानकारी के लिए, Android N में प्राइवेट C/C++ सिंबल के इस्तेमाल पर पाबंदियां लगाकर, ऐप्लिकेशन को ज़्यादा भरोसेमंद बनाना लेख पढ़ें.

क्या dex2oat या DEX फ़ाइल में बदलाव करने पर पाबंदी लगाने का कोई प्लान है?

फ़िलहाल, dex2oat बाइनरी के ऐक्सेस पर पाबंदी लगाने की हमारी कोई योजना नहीं है. हालांकि, हमारा इरादा DEX फ़ाइल फ़ॉर्मैट को स्थिर या सार्वजनिक इंटरफ़ेस बनाने का नहीं है. यह सिर्फ़ उन हिस्सों के लिए है जो Dalvik Executable फ़ॉर्मैट में सार्वजनिक तौर पर तय किए गए हैं. हमारे पास किसी भी समय, dex2oat और DEX फ़ॉर्मैट के कुछ हिस्सों में बदलाव करने या उन्हें हटाने का अधिकार है. यह भी ध्यान दें कि dex2oat से बनाई गई फ़ाइलें, जैसे कि ODEX (इसे OAT भी कहा जाता है), VDEX, और CDEX, सभी ऐसे फ़ॉर्मैट हैं जिनके बारे में जानकारी नहीं दी गई है.

अगर तीसरे पक्ष का कोई ज़रूरी एसडीके (उदाहरण के लिए, कोई ऑबफ़स्केटर) नॉन-एसडीके इंटरफ़ेस का इस्तेमाल करने से नहीं बच सकता, लेकिन Android के आने वाले वर्शन के साथ काम करने का वादा करता है, तो क्या होगा? क्या इस मामले में, Android के साथ काम करने से जुड़ी ज़रूरी शर्तों को पूरा न करने पर भी छूट दी जा सकती है?

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

क्या नॉन-एसडीके इंटरफ़ेस से जुड़ी पाबंदियां, सिस्टम और पहले पक्ष के ऐप्लिकेशन के साथ-साथ सभी ऐप्लिकेशन पर लागू होती हैं, न कि सिर्फ़ तीसरे पक्ष के ऐप्लिकेशन पर?

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