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

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

SDK टूल और ऐसे इंटरफ़ेस के बीच अंतर बताना जो SDK टूल में उपलब्ध नहीं हैं

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

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

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

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

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

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

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

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

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

Android 16 (डेवलपर के लिए झलक)

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

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: a22d5c2fa9c24ec0b864f0680208e9794222d1921114abe3245979143ce6d1c6

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

Android 15

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

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: 40134e205e58922a708c453726b279a296e6a1f34a988abd90cec0f3432ea5a9

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

Android 14

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

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: 7e00db074cbe51c51ff4b411f7b48e98692951395c5c17d069c822cc1d0eae0f

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

Android 13

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

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: 233a277aa8ac475b6df61bffd95665d86aac6eb2ad187b90bf42a98f5f2a11a3

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

Android 12

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

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: 40674ff4291eb268f86561bf687e69dbd013df9ec9531a460404532a4ac9a761

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

Android 11

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

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: a19d839f4f61dc9c94960ae977b2e0f3eb30f880ba1ffe5108e790010b477a56

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

Android 10

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

फ़ाइल: hiddenapi-flags.csv

SHA-256 चेकसम: f22a59c215e752777a114bd9b07b0b6b4aedfc8e49e6efca0f99681771c5bfeb

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

Android 9

Android 9 (एपीआई लेवल 28) के लिए, यहां दी गई टेक्स्ट फ़ाइल में उन गैर-SDK टूल वाले एपीआई की सूची दी गई है जिन पर पाबंदी नहीं लगी है (ग्रे सूची में शामिल हैं): 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() का इस्तेमाल करके परछाई	नतीजों में ऐसे सदस्य नहीं दिखते जो SDK टूल का इस्तेमाल नहीं करते
Class.getDeclaredMethods(), Class.getMethods() का इस्तेमाल करके परछाई	नतीजों में ऐसे सदस्य नहीं दिखते जो SDK टूल का इस्तेमाल नहीं करते
env->GetFieldID() का इस्तेमाल करके JNI	NULL लौटाए गए, NoSuchFieldError फेंक दिए गए
env->GetMethodID() का इस्तेमाल करके JNI	NULL लौटाए गए, NoSuchMethodError फेंक दिए गए

अपने ऐप्लिकेशन में ऐसे इंटरफ़ेस का इस्तेमाल न करें जिनमें SDK टूल नहीं है

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

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

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

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

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

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

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

StrictMode API का इस्तेमाल करके जांच करना

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

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

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

Veridex टूल की सीमाएं ये हैं:

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

विंडो

इसमें Windows के लिए नेटिव बाइनरी उपलब्ध नहीं हैं. हालांकि, Windows Subsystem for Linux (WSL) का इस्तेमाल करके Linux बाइनरी को चलाकर, Windows पर veridex टूल चलाया जा सकता है. इस सेक्शन में दिया गया तरीका अपनाने से पहले, 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 में अपने ऐप्लिकेशन को टेस्टिंग ट्रैक पर अपलोड किया जाता है, तो संभावित समस्याओं का पता लगाने के लिए आपके ऐप्लिकेशन की जांच अपने-आप की जाती है. साथ ही, लॉन्च से पहले की रिपोर्ट जनरेट की जाती है. अगर आपका ऐप्लिकेशन, SDK टूल के बाहर के इंटरफ़ेस का इस्तेमाल करता है, तो लॉन्च से पहले की गई टेस्टिंग की रिपोर्ट में गड़बड़ी या चेतावनी दिखती है. यह इस बात पर निर्भर करता है कि वे इंटरफ़ेस किस सूची में शामिल हैं.

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

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

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

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

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

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

अन्य सवाल

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

सामान्य सवाल

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

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

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

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

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

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

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 एपीआई का इस्तेमाल करके अपने ऐप्लिकेशन की जांच करने से भी रोका जाता है. हम इस सेटिंग का सुझाव नहीं देते.
• 1: SDK टूल में उपलब्ध नहीं होने वाले सभी इंटरफ़ेस का ऐक्सेस चालू करें. हालांकि, SDK टूल में उपलब्ध नहीं होने वाले किसी भी इंटरफ़ेस का इस्तेमाल करने पर, चेतावनियों के साथ लॉग मैसेज प्रिंट करें. इस सेटिंग का इस्तेमाल करके, StrictMode एपीआई का इस्तेमाल करके अपने ऐप्लिकेशन की जांच भी की जा सकती है.
• 2: ब्लॉकलिस्ट में शामिल ऐसे इंटरफ़ेस का इस्तेमाल करने की अनुमति न दें जो आपके टारगेट एपीआई लेवल के लिए, शर्तों के साथ ब्लॉक किए गए हैं.

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

मुझे सिस्टम इमेज में, SDK टूल के अलावा अन्य एपीआई की सूचियां कहां मिल सकती हैं?

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

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

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

मिलते-जुलते ऐप्लिकेशन के साथ काम करने से जुड़े सवाल

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

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, सभी अज्ञात फ़ॉर्मैट हैं.

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

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

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

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