Android 17 का पहला बीटा वर्शन

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

डेवलपर के लिए झलक से आगे

Android ने परंपरागत "डेवलपर के लिए झलक" को कैनरी चैनल से बदल दिया है. "हमेशा चालू रहने वाले" इस नए मॉडल के तीन मुख्य फ़ायदे हैं:

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

Android 17 का शेड्यूल

हम इस बीटा वर्शन से, मार्च में रिलीज़ होने वाले प्लैटफ़ॉर्म के स्टेबल वर्शन पर तेज़ी से स्विच करेंगे. इस माइलस्टोन पर, हम SDK/NDK एपीआई का फ़ाइनल वर्शन उपलब्ध कराएंगे. साथ ही, ऐप्लिकेशन के लिए उपलब्ध सुविधाओं का फ़ाइनल वर्शन भी उपलब्ध कराएंगे. इसके बाद, आपको टेस्टिंग पूरी करने के लिए कई महीने मिलेंगे.

रिलीज़ का एक साल

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

स्क्रीन की दिशा और साइज़ बदलने से जुड़ी पाबंदियां

Android 17 के बीटा वर्शन की रिलीज़ के साथ, हम अपने अडैप्टिव रोडमैप के अगले चरण पर जा रहे हैं: Android 17 (एपीआई लेवल 37) में, डेवलपर के लिए ओरिएंटेशन और रीसाइज़ करने से जुड़ी पाबंदियों को ऑप्ट-आउट करने का विकल्प हटा दिया गया है. ये पाबंदियां, बड़ी स्क्रीन वाले डिवाइसों (sw > 600 dp) पर लागू होती हैं.

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

एसडीके 37 के लिए मुख्य बदलाव

Android 17 को टारगेट करने वाले ऐप्लिकेशन को यह पक्का करना होगा कि वे Android 16 में पेश किए गए मेनिफ़ेस्ट एट्रिब्यूट और रनटाइम एपीआई के साथ काम करते हों. बड़ी स्क्रीन (छोटी डाइमेंशन ≥ 600dp) पर चलाने के दौरान, इन एट्रिब्यूट और एपीआई को अनदेखा किया जाएगा:

छूट और उपयोगकर्ता का कंट्रोल

ये बदलाव सिर्फ़ बड़ी स्क्रीन वाले डिवाइसों के लिए हैं. ये sw600dp से छोटी स्क्रीन वाले डिवाइसों पर लागू नहीं होते. इनमें स्लेट फ़ॉर्म फ़ैक्टर वाले फ़ोन भी शामिल हैं. इसके अलावा, android:appCategory फ़्लैग के आधार पर, गेम के तौर पर कैटगरी में रखे गए ऐप्लिकेशन पर ये पाबंदियां लागू नहीं होती हैं.

यह भी ध्यान रखना ज़रूरी है कि उपयोगकर्ताओं के पास कंट्रोल बना रहे. सिस्टम की आसपेक्ट रेशियो सेटिंग के ज़रिए, ऐप्लिकेशन की डिफ़ॉल्ट सेटिंग का इस्तेमाल करने के लिए ऑप्ट-इन/आउट किया जा सकता है.

कॉन्फ़िगरेशन में हुए बदलावों से जुड़े अपडेट

ऐप्लिकेशन की कंपैटिबिलिटी को बेहतर बनाने के लिए, हम ऐक्टिविटी को फिर से बनाने के डिफ़ॉल्ट तरीके को अपडेट कर रहे हैं. इससे वीडियो चलाने में आने वाली रुकावटों, इनपुट के रुकने, और अन्य तरह की समस्याओं को कम करने में मदद मिलेगी. Android 17 से, सिस्टम कुछ कॉन्फ़िगरेशन में हुए बदलावों के लिए, डिफ़ॉल्ट रूप से गतिविधियों को फिर से शुरू नहीं करेगा. आम तौर पर, इन बदलावों के लिए यूज़र इंटरफ़ेस (यूआई) को फिर से बनाने की ज़रूरत नहीं होती. इनमें ये बदलाव शामिल हैं: CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_UI_MODE (जब सिर्फ़ UI_MODE_TYPE_DESK में बदलाव किया गया हो), CONFIG_TOUCHSCREEN, और CONFIG_COLOR_MODE. इसके बजाय, दौड़ने की गतिविधियों को onConfigurationChanged के ज़रिए ये अपडेट मिलेंगे. अगर आपका ऐप्लिकेशन, इन बदलावों के लिए संसाधनों को फिर से लोड करने के लिए पूरी तरह से रीस्टार्ट होने पर निर्भर करता है, तो अब आपको नए android:recreateOnConfigChanges मेनिफ़ेस्ट एट्रिब्यूट का इस्तेमाल करके, साफ़ तौर पर ऑप्ट-इन करना होगा. इससे यह तय किया जा सकेगा कि कॉन्फ़िगरेशन में हुए किन बदलावों की वजह से, ऐक्टिविटी का पूरा लाइफ़साइकल ट्रिगर होना चाहिए. जैसे, बंद करना, डिस्ट्रॉय करना, और फिर से बनाना. साथ ही, इससे जुड़े कॉन्स्टेंट mcc, mnc, और नए कॉन्स्टेंट keyboard, keyboardHidden, navigation, touchscreen, और colorMode का इस्तेमाल किया जा सकेगा.

अपने ऐप्लिकेशन को तैयार करना

हमने आपके लिए टूल और दस्तावेज़ उपलब्ध कराए हैं, ताकि आपको आसानी हो. हमारी ब्लॉग पोस्ट में, इस बारे में ज़्यादा जानकारी दी गई है. इसमें, आम समस्याओं को हल करने के तरीके बताए गए हैं. ऐप्लिकेशन को, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) की पूरी रेंज में विंडो के साइज़ के लिए, लैंडस्केप और पोर्ट्रेट लेआउट के साथ काम करना होगा. ऐसा इसलिए, क्योंकि स्क्रीन की दिशा या आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को सीमित करने का विकल्प अब उपलब्ध नहीं होगा. हमारा सुझाव है कि Pixel Tablet या Pixel Fold के एम्युलेटर (targetSdkPreview = "CinnamonBun" पर कॉन्फ़िगर किए गए) के साथ Android 17 के बीटा 1 वर्शन का इस्तेमाल करके, अपने ऐप्लिकेशन की जांच करें. इसके अलावा, ऐप्लिकेशन के साथ काम करने वाले फ़्रेमवर्क का इस्तेमाल करके, Android 16 डिवाइसों पर UNIVERSAL_RESIZABLE_BY_DEFAULT को चालू किया जा सकता है.

परफ़ॉर्मेंस

Lock-free MessageQueue

Android 17 में, SDK 37 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को android.os.MessageQueue का नया वर्शन मिलेगा. इसमें लॉक-फ़्री तरीके से लागू किया गया है. नया वर्शन लागू करने से परफ़ॉर्मेंस बेहतर होती है और छूटे हुए फ़्रेम की संख्या कम होती है. हालांकि, इससे उन क्लाइंट को नुकसान पहुंच सकता है जो MessageQueue के निजी फ़ील्ड और तरीकों पर असर डालते हैं.

जनरेशनल गार्बेज कलेक्शन

Android 17 में, ART के Concurrent Mark-Compact collector के लिए, जनरेशनल गारबेज कलेक्शन की सुविधा जोड़ी गई है. इस ऑप्टिमाइज़ेशन में, फ़ुल-हीप कलेक्शन के साथ-साथ, कम संसाधन इस्तेमाल करने वाले यंग-जनरेशन कलेक्शन को ज़्यादा बार शामिल किया जाता है. इसका मकसद, गार्बेज कलेक्शन के लिए सीपीयू के कुल खर्च और समय को कम करना है. Google Play सिस्टम अपडेट के ज़रिए, ART में किए गए सुधारों को Android 12 (एपीआई लेवल 31) और इसके बाद के वर्शन पर काम करने वाले एक अरब से ज़्यादा डिवाइसों पर भी उपलब्ध कराया गया है.

स्टैटिक फ़ाइनल फ़ील्ड अब वाकई फ़ाइनल हो गए हैं

Android 17 से, Android 17 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन, “static final” फ़ील्ड में बदलाव नहीं कर पाएंगे. इससे रनटाइम को परफ़ॉर्मेंस ऑप्टिमाइज़ेशन को ज़्यादा बेहतर तरीके से लागू करने की अनुमति मिलेगी. ऐसा करने की कोशिश करने पर, हमेशा IllegalAccessException दिखेगा. JNI के SetStatic<Type>Field तरीकों के फ़ैमिली ग्रुप के ज़रिए उनमें बदलाव करने पर, ऐप्लिकेशन तुरंत क्रैश हो जाएगा.

कस्टम सूचनाओं को देखने से जुड़ी पाबंदियां

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

ProfilingManager ट्रिगर की परफ़ॉर्मेंस डीबग करने की नई सुविधा

हमने ProfilingManager में कई नए सिस्टम ट्रिगर जोड़े हैं. इनसे आपको परफ़ॉर्मेंस से जुड़ी समस्याओं को ठीक करने के लिए, ज़्यादा जानकारी वाला डेटा इकट्ठा करने में मदद मिलेगी. ये ट्रिगर हैं: TRIGGER_TYPE_COLD_START, TRIGGER_TYPE_OOM, और TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE.

नए सिस्टम ट्रिगर सेट अप करने का तरीका जानने के लिए, ट्रिगर पर आधारित प्रोफ़ाइलिंग और प्रोफ़ाइलिंग डेटा को वापस पाने और उसका विश्लेषण करने से जुड़े दस्तावेज़ देखें.

मीडिया और कैमरा

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

डाइनैमिक कैमरा सेशन अपडेट

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

fun updateCameraSession(session: CameraCaptureSession, newOutputConfigs:  List<OutputConfiguration>)) {
    // Dynamically update the session without closing and reopening
    try {
        
        // Update the output configurations
        session.updateOutputConfigurations(newOutputConfigs)
    } catch (e: CameraAccessException) {
        // Handle error
    }
}

लॉजिकल मल्टी-कैमरा डिवाइस का मेटाडेटा

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

Versatile Video Coding (VVC) के साथ काम करने की सुविधा

Android 17 में, Versatile Video Coding (VVC) स्टैंडर्ड के लिए सहायता जोड़ी गई है. इसमें MediaFormat में video/vvc एमआईएमई टाइप को तय करना, MediaCodecInfo में नई वीवीसी प्रोफ़ाइलें जोड़ना, और MediaExtractor में सहायता को इंटिग्रेट करना शामिल है. यह सुविधा, उन डिवाइसों पर उपलब्ध होगी जिनमें हार्डवेयर डिकोड करने की सुविधा है और जो ड्राइवर के साथ काम करते हैं.

वीडियो रिकॉर्डिंग के लिए एक जैसी क्वालिटी

हमने MediaRecorder में setVideoEncodingQuality() को जोड़ा है. इससे वीडियो एन्कोडर के लिए, कॉन्स्टेंट क्वालिटी (सीक्यू) मोड को कॉन्फ़िगर किया जा सकता है. इससे आपको बिटरेट की सामान्य सेटिंग के अलावा, वीडियो क्वालिटी पर बेहतर कंट्रोल मिलता है.

बैकग्राउंड ऑडियो सुरक्षा कड़ी करना

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

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

निजता और सुरक्षा

क्लियरटेक्स्ट ट्रैफ़िक एट्रिब्यूट के इस्तेमाल पर रोक

android:usesCleartextTraffic एट्रिब्यूट अब काम नहीं करता. अगर आपका ऐप्लिकेशन, Android 17 या इसके बाद के वर्शन को टारगेट करता है और नेटवर्क सिक्योरिटी कॉन्फ़िगरेशन के बिना usesCleartextTraffic="true" पर निर्भर करता है, तो यह डिफ़ॉल्ट रूप से cleartext ट्रैफ़िक को अनुमति नहीं देगा. हमारा सुझाव है कि आप बेहतर कंट्रोल के लिए, नेटवर्क सुरक्षा कॉन्फ़िगरेशन फ़ाइलों पर माइग्रेट करें.

HPKE हाइब्रिड क्रिप्टोग्राफ़ी

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

कनेक्टिविटी और टेलीकॉम

बेहतर वीओआईपी कॉल इतिहास

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

वाई-फ़ाई रेंजिंग और प्रॉक्सिमिटी

वाई-फ़ाई रेंजिंग को बेहतर बनाया गया है. इसमें आस-पास के डिवाइसों का पता लगाने की नई सुविधाएं जोड़ी गई हैं. साथ ही, इसमें लगातार रेंजिंग और सुरक्षित पीयर-टू-पीयर डिस्कवरी की सुविधा भी जोड़ी गई है. Wi-Fi Aware में अपडेट किए गए हैं. इनमें पीयर हैंडल के लिए नए एपीआई और 11az सुरक्षित रेंजिंग के लिए PMKID कैश मेमोरी शामिल है.

डेवलपर की प्रॉडक्टिविटी और टूल

कंपैनियन डिवाइस के ऐप्लिकेशन के लिए अपडेट

हमने डिवाइसों की पहचान करने और अनुमतियों को मैनेज करने की सुविधा को बेहतर बनाने के लिए, CompanionDeviceManager में दो नई प्रोफ़ाइलें जोड़ी हैं:

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

इसके अलावा, CompanionDeviceManager अब डिवाइस को जोड़ने और आस-पास मौजूद डिवाइसों से इंटरैक्ट करने की अनुमति के अनुरोधों के लिए, एक ही डायलॉग बॉक्स दिखाता है. AssociationRequest.Builder में मौजूद नए setExtraPermissions तरीके का इस्तेमाल करके, आस-पास के डिवाइसों से जुड़ी अनुमतियों के प्रॉम्प्ट को मौजूदा असोसिएशन फ़्लो में बंडल किया जा सकता है. इससे उपयोगकर्ता को दिखने वाले डायलॉग की संख्या कम हो जाती है.

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

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

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

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

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

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

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

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

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

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

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