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

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

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

बबल्स

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

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

बबल की सुविधा, Beta 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)
}

कॉन्टैक्ट पिकर

सिस्टम-लेवल के नए कॉन्टैक्ट पिकर 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)

Interactive Chooser resting bounds

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

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

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

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

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

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

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

डेटा प्लान को बेहतर बनाना

मीडिया की क्वालिटी को ऑप्टिमाइज़ करने के लिए, अब आपका ऐप्लिकेशन, स्ट्रीमिंग ऐप्लिकेशन के लिए कैरियर की ओर से तय की गई ज़्यादा से ज़्यादा डेटा दरें पा सकता है. इसके लिए, 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 और यूनिकोड 17 के साथ काम करता है

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

एसएमएस से भेजे गए ओटीपी की सुरक्षा

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

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

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

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

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

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

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

Android 17 का शेड्यूल

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

रिलीज़ का साल

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

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

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

अगर आपने Android के बीटा प्रोग्राम में रजिस्टर किया है, तो आपको Beta 2 का ओटीए (ओवर-द-एयर) अपडेट मिलेगा.

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

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

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

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

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

सभी बाद के प्रीव्यू और बीटा वर्शन के लिए, ओवर-द-एयर अपडेट उपलब्ध होगा.

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

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

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