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

वर्सटाइल वीडियो कोडिंग (वीवीसी) के साथ काम करने की सुविधा

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

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

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

बैकग्राउंड ऑडियो हार्डनिंग

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

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

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

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

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

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

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

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

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

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

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

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