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

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

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

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

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

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

लक्ष्य

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

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

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

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

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

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

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

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

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

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

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

  • पुराने सिस्टम के साथ काम करने वाले ऐसे बग ठीक करना जिनसे कोई नई सुविधा, नए एपीआई, मौजूदा एपीआई में बदलाव या काम करने के तरीके में बदलाव न हो.
  • धोखाधड़ी का पता लगाने या उसका आकलन करने की सुविधाओं को बेहतर बनाया गया है, ताकि वे पुराने सिस्टम के साथ काम कर सकें.

इन सुविधाओं को लागू करने का तरीका, स्टोर पर निर्भर करता है.

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

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

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

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

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

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

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

ऐक्सेस

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

कोड

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 को दिखाया जाता है.

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

जीवनचक्र

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

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

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

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

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

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

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

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

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

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

खास मामले

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

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

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

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

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

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

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

हम यह कोशिश कर रहे हैं कि SDK टूल के रनटाइम से, असली उपयोगकर्ताओं के डिवाइसों पर सिस्टम की परफ़ॉर्मेंस पर कम से कम असर पड़े. इसके लिए, हम कुछ तरीके डिज़ाइन कर रहे हैं. हालांकि, ज़्यादातर मामलों में ऐसा हो सकता है कि Android (Go edition) जैसे कुछ एंट्री-लेवल Android 14 डिवाइसों पर, 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 टूल के रनटाइम प्रोसेस में डाइनैमिक तौर पर लोड कर सकें. साथ ही, प्रोसेस की स्थिति में हुए बदलावों के बारे में सूचना पा सकें और SDK टूल के रनटाइम में लोड किए गए SDK टूल के साथ इंटरैक्ट कर सकें.

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

ऐप्लिकेशन, SDK टूल के रनटाइम प्रोसेस में चल रहे SDK टूल से इन चरणों के ज़रिए संपर्क करता है:

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

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

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

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

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

लेखन

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

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

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

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

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

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

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

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

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

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

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

बिल्ड

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

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

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

हम अभी इस सुविधा के डिज़ाइन के शुरुआती चरण में हैं. जैसे-जैसे इस सुविधा को तैयार किया जाएगा, हम इस बारे में ज़्यादा जानकारी शेयर करेंगे.

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

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

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

टेस्ट करना

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

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

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

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

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

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

इससे ये फ़ायदे मिलते हैं:

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

SDK टूल को डिस्ट्रिब्यूट करने के लिए, डिस्ट्रिब्यूशन चैनल में ये सुविधाएं होनी चाहिए:

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

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

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

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

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

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

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

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

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

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

    फ़िलहाल, Java पर आधारित रनटाइम, Android उपयोगकर्ताओं को निजता की गारंटी देने के लिए ज़रूरी सुरक्षा सीमाओं को आसानी से लागू नहीं करता. ऐसा करने के लिए, कई सालों तक लगातार काम करना पड़ सकता है. हालांकि, इस बात की कोई गारंटी नहीं है कि यह काम पूरा हो पाएगा. इसलिए, Privacy Sandbox में प्रोसेस की सीमाओं का इस्तेमाल किया जाता है. यह एक ऐसी टेक्नोलॉजी है जिसे समय-समय पर आज़माया गया है और जिसे अच्छी तरह से समझा गया है.

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

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

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

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