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 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) के लिए, यह फ़ाइल डाउनलोड की जा सकती है. इस फ़ाइल में, बिना SDK टूल के सभी इंटरफ़ेस और उनसे जुड़ी सूचियों के बारे में जानकारी दी गई है:

फ़ाइल: 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 से सूचियां जनरेट करना

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

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

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

out/soong/hiddenapi/hiddenapi-flags.csv

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

इस टेबल में बताया गया है कि अगर आपका ऐप्लिकेशन, ब्लॉकलिस्ट में शामिल किसी ऐसे इंटरफ़ेस को ऐक्सेस करने की कोशिश करता है जिसमें 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 टूल वाले इंटरफ़ेस की जांच की जा सकती है.

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

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

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

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

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

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

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

StrictMode API का इस्तेमाल करके, बिना 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 के साथ काम करने की सुविधा से जुड़ा सेक्शन देखें.

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

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

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

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

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

अन्य सवाल

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

सामान्य सवाल

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

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

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

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

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

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

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

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

command:

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 टूल में उपलब्ध नहीं हैं

मुझे सिस्टम इमेज में, बिना 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) के बजाय, निजी प्लैटफ़ॉर्म के एपीआई इस्तेमाल करके बनाए जाते हैं.