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 को कॉल करके, आपका ऐप्लिकेशन उस टारगेट पोज़िशन की पहचान कर सकता है जिस पर ऐनिमेशन और डेटा लोड होने के बाद, चूज़र दिखता है. इससे यूज़र इंटरफ़ेस (यूआई) को बेहतर तरीके से अडजस्ट किया जा सकता है.

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

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

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