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

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

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

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

बबल्स

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

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

बबल की सुविधा, बीटा 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 ऐप्लिकेशन, और कनेक्ट किए गए डिवाइस के कंपैनियन ऐप्लिकेशन जैसे कुछ ऐप्लिकेशन को इस देरी से छूट मिलेगी.

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

Android 17 का शेड्यूल

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

रिलीज़ का साल

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

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

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

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

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

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

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

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

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

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

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

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

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