SDK टूल के रनटाइम की खास जानकारी

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

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

हमने Android 13 में, प्लैटफ़ॉर्म के लिए एक नई सुविधा जोड़ी है. इससे तीसरे पक्ष को SDK टूल को एक खास रनटाइम एनवायरमेंट में चलाया जाता है. इसे SDK टूल का रनटाइम कहा जाता है. SDK टूल का रनटाइम, उपयोगकर्ताओं के डेटा को गारंटी के साथ सुरक्षित तरीके से इकट्ठा करने और शेयर करने के ये बेहतर उपाय देता है:

  • बदला गया एक्ज़ीक्यूशन एनवायरमेंट
  • SDK टूल के लिए, बेहतर तरीके से बताई गई अनुमतियां और डेटा ऐक्सेस करने के अधिकार

हम इस डिज़ाइन के बारे में, मोबाइल ऐप्लिकेशन के विज्ञापन देने वाली कम्यूनिटी से फ़ीडबैक पाना चाहते हैं. हम बड़े डेवलपर समुदाय से भी मिलने वाले सुझावों का स्वागत करते हैं, ताकि यह SDK टूल के रनटाइम को बेहतर बनाने में मदद करता है. साथ ही, इस्तेमाल के कुछ अन्य उदाहरण भी हैं.

लक्ष्य

इस प्रस्ताव का मकसद ये लक्ष्य हासिल करना है:

  • प्रोसेस को अलग-अलग रखने और एपीआई और डेटा ऐक्सेस कंट्रोल को बेहतर तरीके से तय करने की मदद से, तीसरे पक्ष के SDK टूल के ज़रिए उपयोगकर्ता के ऐप्लिकेशन डेटा को बिना बताए ऐक्सेस और शेयर करने की सुविधा को कम करें. इस दस्तावेज़ के अलग सेक्शन में, प्रोसेस को अलग रखने के बारे में ज़्यादा जानें.
  • तीसरे पक्ष के SDK टूल की मदद से, उपयोगकर्ता के ऐप्लिकेशन के इस्तेमाल को बिना बताए ट्रैक करने की सुविधा को कम करें. इसके लिए, SDK टूल के लिए यूनीक और लगातार मौजूद रहने वाले आइडेंटिफ़ायर को ऐक्सेस करने की सुविधा को सीमित करें.
  • SDK टूल के अपडेट को ज़्यादा तेज़ी से उपलब्ध कराने के लिए, पर ज़्यादा बोझ नहीं पड़ता है. इस दस्तावेज़ के किसी दूसरे सेक्शन में, भरोसेमंद SDK टूल के डिस्ट्रिब्यूशन के लिए सुझाए गए मॉडल के बारे में ज़्यादा जानें.
  • डेटा को ऐक्सेस करने और उसे शेयर करने के तरीकों को बेहतर तरीके से समझने में ऐप्लिकेशन डेवलपर की मदद करना उसके ऐप्लिकेशन के बारे में बात करते हैं.
  • SDK टूल के डेवलपर को, JNI कोड जैसी कुछ असुरक्षित भाषा के कॉन्स्ट्रक्ट को सीमित करके, अन्य SDK टूल से होने वाली गड़बड़ी को रोकने में मदद करता है.
  • विज्ञापन दिखाने के लिए इस्तेमाल किए जाने वाले SDK टूल को, मीडिया दिखाने वाले रिमोट व्यू पर पूरा कंट्रोल देकर, अमान्य ट्रैफ़िक और विज्ञापन धोखाधड़ी का पता लगाने और उसे रोकने में मदद करता है.
  • ऐप्लिकेशन और SDK टूल के डेवलपर पर, ज़्यादा से ज़्यादा असर न पड़े.

SDK टूल, अलग-अलग प्रोसेस में काम करते हैं

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

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

SDK टूल के लिए नया भरोसेमंद डिस्ट्रिब्यूशन मॉडल

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

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

  1. SDK टूल के डेवलपर, अपने ऐप्लिकेशन के अलावा, अलग से भी ऐप्लिकेशन स्टोर पर अपने SDK टूल के वर्शन अपलोड कर सकते हैं.
  2. ऐप्लिकेशन डेवलपर, SDK टूल की डिपेंडेंसी के वर्शन के हिसाब से जानकारी दे सकते हैं. साथ ही, वे ऐसी ऐप्लिकेशन रिलीज़ बना सकते हैं और अपलोड कर सकते हैं जिसमें असल SDK टूल की डिपेंडेंसी शामिल न हों.
  3. जब कोई उपयोगकर्ता इस ऐप्लिकेशन को डाउनलोड करता है, तो इंस्टॉल करने की प्रोसेस में ऐप्लिकेशन के हिसाब से तय SDK टूल डिपेंडेंसी का इस्तेमाल करके, उन्हें ऐप स्टोर से डाउनलोड किया जा सकता है.

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

यहां दिए गए डायग्राम में, एसडीके डिस्ट्रिब्यूशन में किए जाने वाले बदलावों के बारे में बताया गया है:

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

SDK टूल और ऐप्लिकेशन बनाने, चलाने, और डिस्ट्रिब्यूट करने के तरीके में बदलाव

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

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

इस दस्तावेज़ में, अक्सर पूछे जाने वाले सवाल भी शामिल हैं. इनसे आपको सामान्य सवालों के जवाब पाने में मदद मिलेगी.

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

ऐक्सेस

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

SDK टूल से जुड़ी अनुमतियां

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

  • INTERNET: किसी वेब सेवा से संपर्क करने के लिए इंटरनेट का ऐक्सेस.
  • ACCESS_NETWORK_STATE: नेटवर्क की जानकारी ऐक्सेस करना.
  • READ_BASIC_PHONE_STATE: फ़ोन की स्थिति के बारे में जानकारी ऐक्सेस करना, जैसे कि मोबाइल नेटवर्क का टाइप.
  • निजता बनाए रखने वाले एपीआई को ऐक्सेस करने की अनुमतियां दी जाती हैं, जिनमें मुख्य विज्ञापन दिखाने के लिए, क्रॉस-ऐप्लिकेशन आइडेंटिफ़ायर के ऐक्सेस की ज़रूरत नहीं है.
  • AD_ID: विज्ञापन आईडी का अनुरोध करने की सुविधा. यह ऐप्लिकेशन के इस अनुमति को ऐक्सेस करें.

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

मेमोरी

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

स्टोरेज

इस प्रस्ताव का मकसद यह है कि SDK टूल को, इसका इस्तेमाल करके क्रॉस-ऐप्लिकेशन और पूरी प्रोसेस की ट्रैकिंग को कम से कम किया जा सकता है. स्थायी स्टोरेज. हम स्टोरेज को ऐक्सेस करने के मौजूदा तरीके में ये अपडेट करने का सुझाव दे रहे हैं:

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

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

प्लान लागू करना

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

कोड

Android कोड (ऐप्लिकेशन और SDK टूल) को मुख्य रूप से Android रनटाइम (ART) सेड्यूस किया जाता है. भले ही, कोड को Kotlin या Java में लिखा गया हो. ART की समृद्धि और उसे ऑफ़र की जाने वाली भाषा के साथ-साथ, उसकी पुष्टि करने की सुविधा भी मिलती है जब विकल्प के साथ तुलना की जाती है—तो खास तौर पर नेटिव कोड में—ठीक तरह से दिखता है बैलेंस की सुविधा और निजता. हमारा सुझाव है कि रनटाइम के साथ काम करने वाले SDK टूल के कोड में, JNI ऐक्सेस की सुविधा के बजाय सिर्फ़ Dex बाइटकोड शामिल किया जाए.

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

SELinux

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

  • सिस्टम की कुछ सेवाओं को ऐक्सेस किया जा सकेगा. (डिज़ाइन में बदलाव किया जा रहा है)
  • SDK टूल, सिर्फ़ अपने APK में कोड लोड और एक्ज़ीक्यूट कर पाएंगे.
  • सिस्टम प्रॉपर्टी के सीमित सेट को ऐक्सेस किया जा सकेगा. (डिज़ाइन में बदलाव किया जा रहा है)

API

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

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

SDK टूल के रनटाइम एपीआई को सिर्फ़ फ़ोरग्राउंड में चल रहे ऐप्लिकेशन से ऐक्सेस किया जा सकता है. ऐप्लिकेशन से SdkSandboxManager एपीआई को ऐक्सेस करने की कोशिश की जा रही है बैकग्राउंड में इस्तेमाल करने से नतीजे के तौर पर SecurityException थ्रो किया जा रहा है.

आखिर में, री-SDK टूल उपयोगकर्ता को सूचनाएं भेजने के लिए, सूचनाओं के एपीआई का इस्तेमाल नहीं कर सकता: किसी भी समय.

जीवनचक्र

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

  • उपयोगकर्ता या ऑपरेटिंग सिस्टम, ऐप्लिकेशन को बंद कर सकते हैं. इसके तुरंत बाद, SDK Runtime अपने-आप बंद हो जाएगा.

  • मेमोरी की वजह से, ऑपरेटिंग सिस्टम SDK टूल के रनटाइम को बंद कर सकता है उदाहरण के लिए, SDK टूल में प्रेशर या बिना कार्रवाई वाला कोई अपवाद.

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

    Android 14 और इसके बाद के वर्शन के लिए, ऐप्लिकेशन और SDK टूल के रनटाइम की प्रोसेस की प्राथमिकताएं अलाइन की जाती हैं. ऐप्लिकेशन और SDK टूल के रनटाइम के लिए, ActivityManager.RunningAppProcessInfo.importance की प्रोसेस की प्राथमिकताएं एक जैसी होनी चाहिए.

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

    • इस प्रपोज़ल में, ऐप्लिकेशन डेवलपर को लाइफ़साइकल से जुड़े कॉलबैक मैथड दिए गए हैं. इनकी मदद से, यह पता लगाया जा सकता है कि SDK टूल का रनटाइम कब खत्म हुआ.
    • अगर विज्ञापन दिखाए जाने के दौरान SDK टूल का रनटाइम खत्म हो जाता है, तो हो सकता है कि विज्ञापन उम्मीद के मुताबिक काम करते हैं. उदाहरण के लिए, हो सकता है कि दृश्य स्क्रीन पर फ़्रीज़ किए जाएं और ज़्यादा इंटरैक्टिव. अगर विज्ञापन व्यू पर कोई असर नहीं पड़ता है, तो ऐप्लिकेशन उसे हटा सकता है उपयोगकर्ता अनुभव मिलता है.
    • ऐप्लिकेशन, SDK टूल लोड करने और विज्ञापनों का अनुरोध करने की कोशिश फिर से कर सकता है.
    • Android 14 के लिए, अगर SDK टूल के रनटाइम में SDK टूल लोड होने के दौरान उसे बंद कर दिया जाता है और ऐप्लिकेशन डेवलपर ने ऊपर बताए गए लाइफ़साइकल कॉलबैक के तरीकों को रजिस्टर नहीं किया है, तो ऐप्लिकेशन डिफ़ॉल्ट रूप से बंद हो जाता है. सिर्फ़ वे ऐप्लिकेशन प्रोसेस बंद हो जाती हैं और सामान्य तरीके से बाहर निकल जाती हैं जिनमें SDK टूल लोड किए गए हैं.
    • SDK टूल के साथ इंटरैक्ट करने के लिए, SDK टूल से मिले बाइंडर ऑब्जेक्ट (जैसे कि SandboxedSdk) का इस्तेमाल करने पर, ऐप्लिकेशन DeadObjectException दिखाता है.

    आने वाले समय में, लाइफ़साइकल के इस मॉडल में बदलाव हो सकता है.

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

गैर-आरई SDK टूल, उनके लिए उपलब्ध स्टैंडर्ड ओएस प्रिमिटिव का इस्तेमाल जारी रख सकते हैं एम्बेड किया गया ऐप्लिकेशन. इसमें सेवाएं, गतिविधियां, और ब्रॉडकास्ट शामिल हैं. वहीं दूसरी ओर, आरई SDK टूल नहीं कर सकते.

खास मामले

यहां दिए गए मामलों में, पुष्टि नहीं की जा सकती और इन मामलों में ऐसा व्यवहार देखने को मिल सकता है:

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

मीडिया रेंडरिंग

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

नेटिव विज्ञापन जिन्हें SDK टूल से रेंडर नहीं किया जाता, बल्कि ऐप्लिकेशन से रेंडर किया जाता है SDK टूल के रनटाइम में SDK टूल के साथ काम करती हो. सिग्नल इकट्ठा करना और वीडियो बनाना नॉन-नेटिव विज्ञापनों के मामले में, फ़ेच करने की प्रोसेस लगातार जारी रहेगी. यह है जांच का क्षेत्र सक्रिय है.

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

सिस्टम की परफ़ॉर्मेंस

हम यह कोशिश कर रहे हैं कि SDK टूल के रनटाइम से, उपयोगकर्ता के डिवाइसों पर सिस्टम की परफ़ॉर्मेंस पर कम से कम असर पड़े. इसके लिए, हम कुछ तरीके डिज़ाइन कर रहे हैं. हालांकि, ज़्यादातर मामलों में ऐसा हो सकता है कि Android (Go edition) जैसे कुछ एंट्री-लेवल Android 13 डिवाइसों पर, SDK टूल के रनटाइम का इस्तेमाल न किया जा सके. ऐसा इसलिए, क्योंकि इन डिवाइसों में सिस्टम के लिए बहुत कम संसाधन होते हैं. हम जल्द ही, SDK टूल के रनटाइम का इस्तेमाल करने के लिए ज़रूरी शर्तों के बारे में बताएंगे.

संचार

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

ऐप्लिकेशन-टू-एसडी

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

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

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

सामान्य इंटरैक्शन मॉडल इस तरह का होगा:

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

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

डायग्राम
ऐप्लिकेशन-टू-SDK टूल को दिखाने वाला क्रम का डायग्राम ऐप्लिकेशन और SDK टूल चालू होने के दौरान इंटरैक्शन.

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

पिछले डायग्राम में दिए गए ग्राफ़ में, ऐप्लिकेशन और SDK टूल के बीच बिना मार्शलिंग लेयर के, निचले लेवल पर.

यह ऐप्लिकेशन, SDK टूल के रनटाइम प्रोसेस में चल रहे SDK टूल से संपर्क करने के लिए, इसके लिए, नीचे दिया गया तरीका अपनाएं:

  1. किसी SDK टूल के साथ इंटरैक्ट करने से पहले, ऐप्लिकेशन यह अनुरोध करेगा कि प्लैटफ़ॉर्म लोड करता है. सिस्टम के सही तरीके से काम करने की पुष्टि करने के लिए, ऐप्लिकेशन अपनी मेनिफ़ेस्ट फ़ाइल में उन SDK टूल के बारे में बताएंगे जिन्हें उन्हें लोड करना है. साथ ही, सिर्फ़ इन SDK टूल को लोड करने की अनुमति होगी.

    यह कोड स्निपेट, एपीआई का उदाहरण देता है:

    SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
    OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)

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

    बाउंड सेवाओं की गाइड में, IBinder देने के अलग-अलग तरीके बताए गए हैं. आप चाहे जो भी तरीका चुनें, वह SDK टूल और कॉलर ऐप है. इस डायग्राम में उदाहरण के तौर पर, एआईडीएल का इस्तेमाल किया गया है.

  3. SdkSandboxManager को IBinder इंटरफ़ेस मिलता है और वह इसे ऐप्लिकेशन पर भेज देता है.

  4. ऐप्लिकेशन, IBinder को इकट्ठा करता है और उसे SDK टूल के इंटरफ़ेस में कास्ट करता है. फ़ंक्शन:

    IBinder binder = sandboxSdk.getInterface();
ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
mySdkInterface.something();

ऐप्लिकेशन, SDK टूल से मीडिया को रेंडर भी कर सकता है. इसके लिए, यह तरीका अपनाएं:

  1. जैसा कि इस के मीडिया रेंडरिंग सेक्शन में बताया गया है दस्तावेज़ के तौर पर इस्तेमाल किया जा सकता है. इससे किसी ऐप्लिकेशन को किसी व्यू में मीडिया को रेंडर करने के लिए SDK टूल मिल सकता है. requestSurfacePackage() पर कॉल करके, सही जानकारी फ़ेच की जा सकती है SurfaceControlViewHost.SurfacePackage.

    यह कोड स्निपेट, एपीआई का उदाहरण देता है:

    SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
        Executor executor,
        OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)

  2. इसके बाद, ऐप्लिकेशन SurfaceView में मौजूद setChildSurfacePackage एपीआई की मदद से, लौटाए गए SurfacePackage को SurfaceView में एम्बेड कर सकता है.

    यहां दिए गए कोड स्निपेट में, एपीआई का उदाहरण दिया गया है:

    SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)

हमारा सुझाव है कि IBinder और requestSurfacePackage() एपीआई, सामान्य हों और ऐप्लिकेशन सीधे तौर पर इनका इस्तेमाल न कर पाएं. इसके बजाय, ये एपीआई को ऊपर बताए गए जनरेट किए गए एपीआई रेफ़रंस के ज़रिए, "शिम" में कॉल किया जाएगा इसकी मदद से, ऐप्लिकेशन डेवलपर के बोझ को कम किया जा सकता है.

SDK टूल से SDK टूल

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

यहां दो मुख्य बातों का ध्यान रखें:

  • जब दोनों SDK टूल, रनटाइम के साथ काम करते हैं. इस मामले में, दोनों SDK टूल साथ ही, SDK टूल का रनटाइम भी इस्तेमाल कर सकते हैं. SDK टूल, इस तरह से संपर्क नहीं कर सकते किस तरह काम करते हैं. इसलिए, SdkSandboxController में एक एपीआई जोड़ा गया है, ताकि लोड किए गए सभी RE-SDK टूल के लिए, SandboxedSdk ऑब्जेक्ट फ़ेच किए जा सकें. इससे री-एसडीके को ये काम करने में मदद मिलती है SDK टूल के रनटाइम में लोड किए गए अन्य SDK टूल के साथ कम्यूनिकेट करने के लिए.
  • जब सिर्फ़ एक SDK टूल, रनटाइम के साथ काम करता है.
    • अगर कॉल करने वाला SDK टूल ऐप्लिकेशन में चल रहा है, तो यह SDK टूल के रनटाइम में दूसरे SDK टूल को कॉल करने वाले ऐप्लिकेशन से अलग नहीं होता.
    • अगर कॉल करने वाला SDK टूल SDK टूल के रनटाइम में चल रहा है, तो इस प्रस्ताव में ऐप्लिकेशन से SDK टूल वाले सेक्शन में बताए गए IBinder का इस्तेमाल करके, किसी तरीके को एक्सपोज़ करने का सुझाव दिया गया है. यह तरीका, ऐप्लिकेशन में मौजूद कोड को सुनता है, प्रोसेस करता है, और दिए गए कॉलबैक के साथ जवाब देता है.
    • जो विज्ञापन SDK टूल रनटाइम के साथ चालू नहीं हैं वे खुद को रजिस्टर नहीं कर सकते, हम एक मीडिएटर SDK टूल बनाने का सुझाव देते हैं, जिसमें कोई भी पार्टनर या ऐप्लिकेशन शामिल हो SDK टूल, ऐप्लिकेशन के लिए डायरेक्ट डिपेंडेंसी के तौर पर काम करते हैं और रजिस्ट्रेशन को मैनेज करते हैं. यह मध्यस्थ SDK टूल, रनटाइम की सुविधा के बिना काम करने वाले SDK टूल या ऐप्लिकेशन की अन्य डिपेंडेंसी के बीच और रनटाइम की सुविधा वाले मध्यस्थ के बीच, अडैप्टर के तौर पर काम करके, कम्यूनिकेशन की सुविधा देता है.

SDK टूल और SDK टूल के बारे में जानकारी देने के लिए, सुविधाओं के सेट को इनमें बांटा गया है श्रेणियां:

  • SDK टूल के रनटाइम में, SDK टूल के बीच कम्यूनिकेशन (डेवलपर के लिए उपलब्ध सबसे नए रिलीज़ में उपलब्ध)
  • ऐप्लिकेशन और SDK टूल के रनटाइम के बीच, SDK टूल और SDK टूल के बीच कम्यूनिकेशन. यह डेवलपर की नई झलक)
  • मीडिएशन के लिए व्यू और रिमोट रेंडरिंग कैसे काम करनी चाहिए (प्रपोज़ल पर काम जारी है)

इस्तेमाल के इन उदाहरणों पर विचार किया जा रहा है, क्योंकि प्रिमिटिव को डिज़ाइन किया गया:

  1. मीडिएशन और बिडिंग. विज्ञापन दिखाने वाले कई SDK टूल, मीडिएशन या बिडिंग की सुविधा देते हैं. इसमें, SDK टूल किसी विज्ञापन इंप्रेशन (मीडिएशन) के लिए या नीलामी (बिडिंग) चलाने के लिए सिग्नल इकट्ठा करने के लिए, कई अन्य SDK टूल को कॉल करता है. आम तौर पर, कोऑर्डिनेट करने वाला SDK टूल, कोऑर्डिनेट करने वाले SDK टूल से मिले अडैप्टर की मदद से, दूसरे SDK टूल को कॉल करता है. ऊपर दिए गए प्राइमिटिव के हिसाब से, सामान्य तरीके से काम करने के लिए, कोऑर्डिनेट करने वाला SDK टूल, RE या नॉन-RE, सभी RE और नॉन-RE SDK टूल को ऐक्सेस कर सकता है. इस संदर्भ में रेंडरिंग की जांच की जा रही है.
  2. सुविधा का पता लगाना. कुछ SDK टूल में छोटे SDK टूल होते हैं. ये इंटर-SDK डिस्कवरी की प्रोसेस की मदद से, ऐप्लिकेशन डेवलपर को दिखाए जाने वाले फ़ीचर सेट का पता लगाते हैं. रजिस्ट्रेशन और डिस्कवरी प्रिमिटिव उम्मीद है कि यह इस्तेमाल के इस उदाहरण को चालू कर देगा.
  3. पब्लिशर की सदस्यता के मॉडल. कुछ SDK टूल को इस तरह से डिज़ाइन किया गया है कि उनमें इवेंट का एक मुख्य पब्लिशर हो. अन्य SDK टूल या ऐप्लिकेशन, कॉलबैक की मदद से सूचनाएं पाने के लिए इस पब्लिशर की सदस्यता ले सकते हैं. ऊपर दिए गए प्राइमिटिव, इस इस्तेमाल के उदाहरण के साथ काम करने चाहिए.

ऐप्लिकेशन-टू-ऐप्लिकेशन

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

  • SDK टूल, <service>, <contentprovider> या <activity> के मेनिफ़ेस्ट में किया गया है.
  • SDK टूल, ContentProvider को पब्लिश नहीं कर सकता या ब्रॉडकास्ट नहीं कर सकता.
  • SDK टूल, किसी दूसरे ऐप्लिकेशन की ऐक्टिविटी लॉन्च कर सकता है. हालांकि, इंटेंट में क्या भेजा जा सकता है, इस पर पाबंदियां हैं. उदाहरण के लिए, कोई भी अतिरिक्त या कस्टम ऐक्शन को इस इंटेंट में जोड़ा जाएगा.
  • SDK टूल, सिर्फ़ अनुमति वाली सेवाओं को शुरू या उनसे बंधा जा सकता है.
  • एसडीके टूल, सिस्टम ContentProvider (जैसे, com.android.providers.settings.SettingsProvider) का सिर्फ़ एक सबसेट ऐक्सेस कर सकता है. इस सबसेट में, मिले डेटा में आइडेंटिफ़ायर नहीं होते और इसका इस्तेमाल उपयोगकर्ता का फ़िंगरप्रिंट बनाने के लिए नहीं किया जा सकता. ये जांच, ContentResolver का इस्तेमाल करके ContentProvider को ऐक्सेस करने पर भी लागू होती हैं.
  • SDK टूल, सुरक्षित ब्रॉडकास्ट रिसीवर के कुछ सबसेट को ही ऐक्सेस कर सकता है (जैसे android.intent.action.AIRPLANE_MODE के तौर पर).

मेनिफ़ेस्ट टैग

SDK टूल इंस्टॉल होने के बाद, PackageManager SDK टूल के मेनिफ़ेस्ट को पार्स करता है और काम नहीं करता का इस्तेमाल करें. उदाहरण के लिए, हो सकता है कि SDK टूल, <service>, <activity>, <provider> या <receiver> जैसे कॉम्पोनेंट की जानकारी न दे और मेनिफ़ेस्ट में <permission> का एलान न करे. फ़ेल हुए टैग SDK टूल के रनटाइम में, ऐप्लिकेशन इंस्टॉल नहीं किए जा सकते. ऐसे टैग जो इंस्टॉल नहीं होते, लेकिन चुपचाप अनदेखा कर दिए जाते हैं, हो सकता है कि वे Android के आने वाले वर्शन में काम करें.

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

गतिविधि से जुड़ी सहायता

SDK टूल के रनटाइम एनवायरमेंट में मौजूद SDK टूल, अपनी मेनिफ़ेस्ट फ़ाइल में गतिविधि टैग नहीं जोड़ सकते. साथ ही, Context.startActivity का इस्तेमाल करके अपनी गतिविधियां शुरू नहीं कर सकते. इसके बजाय, यह प्लैटफ़ॉर्म, अनुरोध किए जाने पर SDK टूल के लिए गतिविधियां बनाता है और SDK टूल के साथ उन्हें शेयर करता है.

प्लैटफ़ॉर्म के लिए गतिविधि android.app.Activity टाइप की है. प्लैटफ़ॉर्म गतिविधि, ऐप्लिकेशन की किसी एक गतिविधि से शुरू होती है और यह ऐप्लिकेशन टास्क का हिस्सा होती है. FLAG_ACTIVITY_NEW_TASK का इस्तेमाल नहीं किया जा सकता.

किसी SDK टूल को गतिविधि शुरू करने के लिए, उसे SdkSandboxActivityHandler टाइप का एक इंस्टेंस रजिस्टर करना चाहिए. इसका इस्तेमाल, गतिविधि शुरू करने के लिए ऐप्लिकेशन के SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) को कॉल करने पर, गतिविधि बनाने के बारे में सूचना देने के लिए किया जाता है.

किसी गतिविधि का अनुरोध करने का फ़्लो, नीचे दिए गए ग्राफ़ में दिखाया गया है.

डायग्राम
सीक्वेंस का डायग्राम जो कोई गतिविधि शुरू करने की प्रोसेस को दिखाता है.

डेवलेपमेंट

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

लेखन

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

ऐप्लिकेशन डेवलपर

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

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

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

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

SDK टूल के डेवलपर

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

  • नाम: SDK टूल या लाइब्रेरी का पैकेज नाम.
  • मेजर वर्शन: SDK टूल का मेजर वर्शन कोड.
  • माइनर वर्शन: SDK टूल का माइनर वर्शन कोड.

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

आरई SDK टूल के डेवलपर, उन ऐप्लिकेशन के लिए सहायता करना जारी रख सकते हैं जो फिर से चालू नहीं हैं डिवाइस, जैसे कि Android 12 या उससे पहले के वर्शन. साथ ही, जैसा कि System Health सेक्शन में, कम सुविधाओं वाले वे Android 13 डिवाइस मौजूद हैं जो सीमित सिस्टम संसाधन. हम SDK टूल को पक्का करने के लिए काम कर रहे हैं डेवलपर, आरई और नॉन-आरई एनवायरमेंट के साथ काम करने के लिए एक ही कोड-बेस का इस्तेमाल कर सकते हैं.

बिल्ड

ऐप्लिकेशन डेवलपर

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

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

हम अभी डिज़ाइन के चरण में ही हैं. जैसे-जैसे यह पूरा होगा, हम इसके बारे में ज़्यादा जानकारी शेयर करेंगे.

SDK टूल के डेवलपर

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

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

टेस्ट करना

ऐप्लिकेशन डेवलपर

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

SDK टूल के डेवलपर

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

डिस्ट्रिब्यूशन

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

  • SDK टूल की क्वालिटी और एकरूपता को पक्का करना.
  • SDK टूल के डेवलपर के लिए, कॉन्टेंट पब्लिश करने की प्रोसेस को आसान बनाएं.
  • इंस्टॉल किए गए ऐप्लिकेशन में, SDK टूल के माइनर वर्शन के अपडेट को तेज़ी से रोल आउट करना.

SDK टूल के डिस्ट्रिब्यूशन की सुविधा के लिए, ऐप स्टोर को नीचे दी गई ज़्यादातर सुविधाएं उपलब्ध कराई जा सकती हैं:

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

समय के साथ बदलती पाबंदियां

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

इसके अलावा, हम एक कैनरी सिस्टम बना रहे हैं, ताकि बाहरी और अंदरूनी टेस्टर को किसी ऐसे ग्रुप में शामिल करने के लिए अनुमति लेना जिसे अगले Android का एक वर्शन है. इससे हमें पाबंदियों के सेट में किए गए सुझाए गए बदलावों के बारे में सुझाव और भरोसा पाने में मदद मिलेगी.

अक्सर पूछे जाने वाले सवाल

  1. विज्ञापन से जुड़ा एसडीके टूल क्या होता है?

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

  2. क्या SDK टूल के रनटाइम में कोई SDK टूल चलाया जा सकता है?

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

  3. प्रोसेस के Java-based रनटाइम में अलग-अलग प्रोसेस को अलग-अलग रखने के बजाय, प्रोसेस को अलग-अलग रखने का विकल्प क्यों चुनना चाहिए?

    इस समय, Java पर आधारित रनटाइम, सुरक्षा के लिए आसानी से Android के लिए, निजता की सुरक्षा का ध्यान रखने के लिए ज़रूरी सीमाएं उपयोगकर्ता. कुछ ऐसा लागू करने का प्रयास करने के लिए, आपके विज्ञापन को और सफलता की गारंटी के बिना, कई सालों तक काम करने की कोशिश करते हैं. इसलिए, निजता सैंडबॉक्स में प्रोसेस की सीमाएं तय की गई हैं. यह लंबे समय तक समझने लायक और समझने में आसान इस्तेमाल होती है टेक्नोलॉजी.

  4. क्या SDK टूल को SDK टूल के रनटाइम प्रोसेस में ले जाने से, डाउनलोड किए जाने वाले ऐप्लिकेशन के साइज़ या डिवाइस के स्टोरेज में बचत होगी?

    अगर एक ही वर्शन के रनटाइम के साथ काम करने वाले SDK टूल के साथ कई ऐप्लिकेशन इंटिग्रेट किए जाते हैं, तो इससे डाउनलोड साइज़ और डिस्क स्टोरेज कम हो सकता है.

  5. ऐप्लिकेशन के किस तरह के लाइफ़साइकल इवेंट होते हैं. जैसे, जब ऐप्लिकेशन किसी बैकग्राउंड में, क्या SDK टूल के रनटाइम में SDK टूल का ऐक्सेस मिलेगा?

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