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

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

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

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

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

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

लक्ष्य

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

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

SDK टूल, आइसोलेट की गई प्रोसेस में काम करते हैं

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

---

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

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

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

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

इस प्रोसेस में ये चरण शामिल हैं:

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

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

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

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

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

---

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

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

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

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

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

ऐक्सेस

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

एसडीके टूल की अनुमतियां

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

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

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

मेमोरी

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

स्टोरेज

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

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

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

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

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

कोड

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

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

SELinux

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

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

API

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

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

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

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

जीवनचक्र

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

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

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

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

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

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

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

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

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

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

खास मामले

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

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

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

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

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

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

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

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

संचार

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

ऐप्लिकेशन से एसडीके तक

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. ऐप्लिकेशन को IBinder मिलता है और वह इसे एसडीके इंटरफ़ेस में कास्ट करता है. इसके बाद, वह इसके फ़ंक्शन को कॉल करता है:

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

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

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

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

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

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

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

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

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

एसडीके से एसडीके

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

यहां दो मुख्य केस दिए गए हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डेवलेपमेंट

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

लेखन

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

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

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

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

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

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

एसडीके डेवलपर

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

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

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

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

बिल्ड

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

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

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

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

एसडीके डेवलपर

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

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

टेस्ट करना

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

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

एसडीके डेवलपर

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

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

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

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

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

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

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

समय के साथ पाबंदियों में बदलाव होना

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

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

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

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

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

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

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

3. किसी प्रोसेस के Java-आधारित रनटाइम में आइसोलेशन के बजाय, प्रोसेस आइसोलेशन को क्यों चुना जाता है?

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

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

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

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

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

आपके लिए सुझाव

• ध्यान दें: JavaScript बंद होने पर लिंक का टेक्स्ट दिखता है
• एसडीके रनटाइम के लिए डेवलपर गाइड