Android 17 का दूसरा बीटा वर्शन

आज हम Android 17 का दूसरा बीटा वर्शन रिलीज़ कर रहे हैं. हम ऐसा प्लैटफ़ॉर्म बनाने की कोशिश कर रहे हैं जो निजता, सुरक्षा, और बेहतर परफ़ॉर्मेंस को प्राथमिकता देता हो.इस अपडेट में कई नई सुविधाएं जोड़ी गई हैं. इनमें EyeDropper API और निजता बनाए रखने वाला Contacts Picker शामिल है. हम इसमें बेहतर रेंजिंग, क्रॉस-डिवाइस हैंडऑफ़ एपीआई वगैरह भी जोड़ रहे हैं.

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

उपयोगकर्ता अनुभव और सिस्टम यूज़र इंटरफ़ेस (यूआई)

बबल्स

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

आपको मल्टी-विंडो मोड के लिए दिए गए दिशा-निर्देशों का पालन करना चाहिए, ताकि यह पक्का किया जा सके कि आपके ऐप्लिकेशन, बबल्स के तौर पर सही तरीके से काम करें.

फ़िलहाल, बीटा 2 में बबल्स की सुविधा पूरी तरह से चालू नहीं है. यह सुविधा, Android 17 के आने वाले वर्शन में उपलब्ध होगी.

EyeDropper API

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

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
  result -> if (result.resultCode == Activity.RESULT_OK) {
    val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
    // Use the picked color in your app
  }
}

fun launchColorPicker() {
  val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
  eyeDropperLauncher.launch(intent)
}

Contacts Picker

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

val contactPicker = rememberLauncherForActivityResult(StartActivityForResult()) {
    if (it.resultCode == RESULT_OK) {
        val uri = it.data?.data ?: return@rememberLauncherForActivityResult
        // Handle result logic
        processContactPickerResults(uri)
    }
}

val dataFields = arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE)
val intent = Intent(ACTION_PICK_CONTACTS).apply {
    putStringArrayListExtra(EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, dataFields)
    putExtra(EXTRA_ALLOW_MULTIPLE, true)
    putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5)
}

contactPicker.launch(intent)

टचपैड के साथ पॉइंटर कैप्चर करने की सुविधा को बेहतर बनाना

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

// To request the new default relative mode (mouse-like events)
// This is the same as requesting with View.POINTER_CAPTURE_MODE_RELATIVE
view.requestPointerCapture()

// To request the legacy absolute mode (raw touch coordinates)
view.requestPointerCapture(View.POINTER_CAPTURE_MODE_ABSOLUTE)

इंटरैक्टिव चूज़र की रेस्टिंग बाउंड्री

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

कनेक्टिविटी और क्रॉस-डिवाइस

क्रॉस-डिवाइस ऐप्लिकेशन हैंडऑफ़

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

बेहतर रेंजिंग एपीआई

हम रेंजिंग की दो नई टेक्नोलॉजी के लिए सहायता जोड़ रहे हैं -

1. UWB DL-TDOA. इससे ऐप्लिकेशन, इंडोर नेविगेशन के लिए UWB का इस्तेमाल कर सकते हैं. यह एपीआई सर्फ़ेस, FIRA (फ़ाइन रेंजिंग कंसोर्टियम) 4.0 DL-TDOA की खास जानकारी के मुताबिक है. इससे, निजता को सुरक्षित रखते हुए इंडोर नेविगेशन किया जा सकता है. इसमें ऐंकर की मदद से डिवाइस को ट्रैक नहीं किया जाता.
2. नज़दीकी डिवाइसों का पता लगाने की सुविधा. इससे ऐप्लिकेशन, WFA (वाई-फ़ाई अलायंस) की ओर से अपनाई जा रही, रेंजिंग की नई खास जानकारी का इस्तेमाल कर सकते हैं. यह टेक्नोलॉजी, Wifi Aware पर आधारित रेंजिंग की मौजूदा खास जानकारी के मुकाबले, बेहतर भरोसेमंद और सटीक है.

डेटा प्लान में सुधार

मीडिया की क्वालिटी को ऑप्टिमाइज़ करने के लिए, आपका ऐप्लिकेशन अब getStreamingAppMaxDownlinkKbps और getStreamingAppMaxUplinkKbps का इस्तेमाल करके, स्ट्रीमिंग ऐप्लिकेशन के लिए, ऑपरेटर की ओर से तय की गई ज़्यादा से ज़्यादा डेटा रेट हासिल कर सकता है.

मुख्य फ़ंक्शन, निजता, और परफ़ॉर्मेंस

लोकल नेटवर्क का ऐक्सेस

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

टाइम ज़ोन ऑफ़सेट में बदलाव की सूचना ब्रॉडकास्ट करना

Android अब ACTION_TIMEZONE_OFFSET_CHANGED नाम का एक भरोसेमंद ब्रॉडकास्ट इंटेंट उपलब्ध कराता है. यह इंटेंट, सिस्टम के टाइम ज़ोन ऑफ़सेट में बदलाव होने पर ट्रिगर होता है. जैसे, डेलाइट सेविंग टाइम ट्रांज़िशन के दौरान. यह, ACTION_TIME_CHANGED और ACTION_TIMEZONE_CHANGED नाम के मौजूदा ब्रॉडकास्ट इंटेंट के साथ काम करता है. ये इंटेंट, Unix टाइमस्टैंप में बदलाव होने और टाइम ज़ोन आईडी में बदलाव होने पर ट्रिगर होते हैं.

एनपीयू मैनेजमेंट और प्राथमिकता तय करना

Android 17 को टारगेट करने वाले जिन ऐप्लिकेशन को सीधे तौर पर एनपीयू को ऐक्सेस करना है उन्हें अपने मेनिफ़ेस्ट में FEATURE_NEURAL_PROCESSING_UNIT का एलान करना होगा, ताकि एनपीयू को ऐक्सेस करने से रोका न जाए. इनमें, LiteRT NPU डेलिगेट, वेंडर के हिसाब से तय किए गए SDK टूल, और NNAPI का इस्तेमाल करने वाले ऐप्लिकेशन शामिल हैं. NNAPI को अब इस्तेमाल नहीं किया जाता.

आईसीयू 78 और यूनिकोड 17 के लिए सहायता

इंटरनैशनलाइज़ेशन की मुख्य लाइब्रेरी को ICU 78 पर अपडेट कर दिया गया है. इससे, नए स्क्रिप्ट, वर्ण, और इमोजी ब्लॉक के लिए सहायता बढ़ गई है. साथ ही, टाइम ऑब्जेक्ट को सीधे फ़ॉर्मैट किया जा सकता है.

ओटीपी वाले एसएमएस की सुरक्षा

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

WebOTP फ़ॉर्मैट वाले एसएमएस को ऐक्सेस करने में देरी

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

ओटीपी वाले स्टैंडर्ड एसएमएस को ऐक्सेस करने में देरी

WebOTP या एसएमएस रिट्रीवर फ़ॉर्मैट का इस्तेमाल न करने वाले, ओटीपी वाले एसएमएस को ज़्यादातर ऐप्लिकेशन के लिए तीन घंटे बाद ही ऐक्सेस किया जा सकेगा. यह बदलाव सिर्फ़ Android 17 (एपीआई लेवल 37) या इसके बाद वाले वर्शन को टारगेट करने वाले ऐप्लिकेशन पर लागू होता है.

डिफ़ॉल्ट एसएमएस, Assistant ऐप्लिकेशन, और कनेक्ट किए गए डिवाइस के साथी ऐप्लिकेशन वगैरह को इस देरी से छूट मिलेगी.

ओटीपी निकालने के लिए, एसएमएस पढ़ने पर निर्भर रहने वाले सभी ऐप्लिकेशन को, एसएमएस रिट्रीवर या एसएमएस उपयोगकर्ता की सहमति वाले एपीआई का इस्तेमाल करना चाहिए, ताकि उनकी सुविधा काम करती रहे.

Android 17 का शेड्यूल

हम इस बीटा वर्शन से, प्लैटफ़ॉर्म की स्थिरता के माइलस्टोन पर तेज़ी से बढ़ेंगे. हमारा लक्ष्य है कि यह माइलस्टोन मार्च में पूरा हो जाए. इस माइलस्टोन पर, हम SDK/NDK एपीआई का फ़ाइनल वर्शन रिलीज़ करेंगे. इसके बाद, आपका ऐप्लिकेशन SDK 37 को टारगेट कर सकता है और Google Play पर पब्लिश किया जा सकता है. इससे आपको Android 17 के सामान्य रूप से उपलब्ध होने से पहले, कई महीनों तक टेस्टिंग पूरी करने और उपयोगकर्ता से सुझाव, शिकायत या राय हासिल करने में मदद मिलेगी.

एक साल में रिलीज़ होने वाले वर्शन

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

Android 17 का इस्तेमाल शुरू करना

Android के बीटा वर्शन के इस और आने वाले अपडेट पाने के लिए, ज़रूरी शर्तें पूरी करने वाले किसी भी Pixel डिवाइस को रजिस्टर किया जा सकता है. ये अपडेट, ओटीए (ओवर-द-एयर) के ज़रिए मिलेंगे. अगर आपके पास Pixel डिवाइस नहीं है, तो Android Studio में Android Emulator के साथ, 64-बिट सिस्टम इमेज का इस्तेमाल किया जा सकता है.

अगर आपने फ़िलहाल Android के बीटा प्रोग्राम के लिए रजिस्टर किया है, तो आपको बीटा 2 का ओटीए अपडेट मिलेगा.

अगर आपके पास Android 26Q1 का बीटा वर्शन है और आपको 26Q1 का फ़ाइनल स्टेबल वर्शन चाहिए और बीटा प्रोग्राम से बाहर निकलना है, तो आपको 26Q2 के बीटा 2 के ओटीए अपडेट को अनदेखा करना होगा. साथ ही, 26Q1 के रिलीज़ होने का इंतज़ार करना होगा.

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

हमारा सुझाव है कि Android 17 के साथ बेहतर डेवलपमेंट अनुभव पाने के लिए, Android Studio (Panda) के नए प्रीव्यू वर्शन का इस्तेमाल करें. सेटअप करने के बाद, आपको ये काम करने चाहिए:

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

हम Android 17 के रिलीज़ साइकल के दौरान, प्रीव्यू/बीटा सिस्टम इमेज और SDK को नियमित तौर पर अपडेट करेंगे. बीटा वर्शन इंस्टॉल करने के बाद, आपको आने वाले समय में अपडेट अपने-आप मिलेंगे

ये अपडेट, ओटीए (ओवर-द-एयर) के ज़रिए, बाद के सभी प्रीव्यू और बीटा वर्शन के लिए मिलेंगे.

पूरी जानकारी के लिए, Android 17 की डेवलपर साइट पर जाएं.

बातचीत में शामिल हों

हम इस साल के आखिर में, प्लैटफ़ॉर्म की स्थिरता और Android 17 के सामान्य रूप से उपलब्ध होने की ओर बढ़ रहे हैं. ऐसे में, आपके सुझाव, शिकायत या राय हमारे लिए सबसे अहम हैं. चाहे आप Canary चैनल पर शुरुआती अडॉप्टर हों या बीटा 2 पर टेस्ट करने वाले ऐप्लिकेशन डेवलपर, हमारी कम्यूनिटी में शामिल हों और सुझाव, शिकायत या राय सबमिट करें. हमें आपकी दिलचस्पी का ख्याल है.