आज हम 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 के ज़रिए, सिस्टम-लेवल के नए Contacts Picker की मदद से, उपयोगकर्ता की ओर से अनुरोध किए गए सिर्फ़ खास डेटा फ़ील्ड को पढ़ने का अस्थायी और सेशन-आधारित ऐक्सेस मिलता है. इससे, 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 (Fine Ranging Consortium) 4.0 DL-TDOA की खास जानकारी के मुताबिक है. इससे, निजता को सुरक्षित रखते हुए इंडोर नेविगेशन किया जा सकता है. इसमें ऐंकर की मदद से डिवाइस को ट्रैक नहीं किया जाता.
2. नज़दीकी डिवाइसों का पता लगाने की सुविधा. इससे ऐप्लिकेशन, WFA (WiFi Alliance) की ओर से अपनाई जा रही, रेंजिंग की नई खास जानकारी का इस्तेमाल कर पाएंगे. यह टेक्नोलॉजी, Wifi Aware पर आधारित रेंजिंग की मौजूदा खास जानकारी के मुकाबले, ज़्यादा भरोसेमंद और सटीक है.

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

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

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

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

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

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

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

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

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

ICU 78 और Unicode 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 डिवाइस को रजिस्टर किया जा सकता है. इससे आपको Android के बीटा वर्शन के मौजूदा और आने वाले अपडेट, ओटीए (ओवर-द-एयर) के ज़रिए मिलेंगे. अगर आपके पास 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 पर टेस्ट करने वाले ऐप्लिकेशन डेवलपर, हमारी कम्यूनिटी में शामिल हों और सुझाव, राय या शिकायत सबमिट करें. हमें आपकी दिलचस्पी का ख्याल है.