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 सिस्टम अपडेट के ज़रिए, 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 नतीजे के कोड के साथ काम नहीं करेगा.

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

Cleartext Traffic Attribute के काम न करने की सुविधा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इस और आने वाले समय में 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 पर टेस्टिंग कर रहे हों, हमारी कम्यूनिटी में शामिल हों और सुझाव/राय दें या शिकायत करें. हम सुन रहे हैं.