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

हमने ओरिएंटेशन और साइज़ बदलने वाले एपीआई में अहम बदलाव किए हैं, ताकि अडैप्टिव व्यवहार को बेहतर बनाया जा सके. साथ ही, हमने आपको कुछ समय के लिए ऑप्ट-आउट करने का विकल्प दिया है, ताकि आप आसानी से बदलाव कर सकें. हमने देखा है कि एपीआई लेवल 36 को टारगेट करते समय, कई डेवलपर ने इस बदलाव को अपना लिया है.

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

इन बदलावों से यह पक्का किया जाता है कि Android नेटवर्क पर, सभी डिवाइसों पर एक जैसा और अच्छी क्वालिटी का अनुभव मिले.

Android 17 में क्या बदलाव हो रहे हैं

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

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

ध्यान दें: जैसा कि Android 16 के बारे में पहले बताया गया था, ये बदलाव sw 600 dp से छोटी स्क्रीन या android:appCategory फ़्लैग के आधार पर गेम के तौर पर कैटगरी में रखे गए ऐप्लिकेशन पर लागू नहीं होते. 

साथ ही, उपयोगकर्ताओं के पास कंट्रोल रहता है. आस्पेक्ट रेशियो की सेटिंग में जाकर, उपयोगकर्ता ऐप्लिकेशन के अनुरोध किए गए व्यवहार का इस्तेमाल करने के लिए ऑप्ट-इन कर सकते हैं.

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

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

अपने ऐप्लिकेशन की जांच करना

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

Android Studio में Pixel Tablet और Pixel Fold सीरीज़ के एम्युलेटर के साथ Android 17 Beta 1 का इस्तेमाल करें. साथ ही, targetSdkPreview = “CinnamonBun” सेट करें. इसके अलावा, अगर आपका ऐप्लिकेशन अब तक एपीआई लेवल 36 को टारगेट नहीं करता है, तो UNIVERSAL_RESIZABLE_BY_DEFAULT फ़्लैग चालू करके, ऐप्लिकेशन के साथ काम करने वाले फ़्रेमवर्क का इस्तेमाल किया जा सकता है.

हमारे पास कुछ और टूल हैं. इनकी मदद से यह पक्का किया जा सकता है कि आपके लेआउट सही तरीके से अडजस्ट हों. Compose UI Check का इस्तेमाल करके, अपने यूज़र इंटरफ़ेस (यूआई) की अपने-आप ऑडिट की जा सकती है. साथ ही, यूआई को ज़्यादा अडैप्टिव बनाने के लिए सुझाव पाए जा सकते हैं. इसके अलावा, DeviceConfigurationOverride का इस्तेमाल करके, टेस्ट में डिसप्ले की खास विशेषताओं को सिम्युलेट किया जा सकता है.

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

आइए, इन सामान्य समस्याओं को हल करने के लिए कुछ रणनीतियों पर एक नज़र डालें.

देखें कि कैमरा, ऐप्लिकेशन के साथ काम करता हो

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

पक्का करें कि कैमरे की झलक वाली इमेज न तो खिंची हुई हो और न ही घुमाई गई हो.

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

यह पक्का करने के लिए कि कैमरे की झलक, विंडो के किसी भी साइज़ या ओरिएंटेशन के हिसाब से सही तरीके से अडजस्ट हो, इन चार समाधानों को आज़माएं:

पहला तरीका: Jetpack CameraX (सुझाया गया) 

सबसे आसान और भरोसेमंद तरीका, Jetpack CameraX लाइब्रेरी का इस्तेमाल करना है. इसके PreviewView यूज़र इंटरफ़ेस (यूआई) एलिमेंट को, झलक से जुड़ी सभी मुश्किलों को अपने-आप मैनेज करने के लिए डिज़ाइन किया गया है:

• PreviewView सेंसर के ओरिएंटेशन, डिवाइस के रोटेशन, और स्केलिंग के हिसाब से सही तरीके से अडजस्ट होता है
• PreviewView, कैमरे की इमेज के आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को बनाए रखता है. आम तौर पर, यह इमेज को बीच में रखकर और काटकर ऐसा करता है (FILL_CENTER)
• अगर ज़रूरत हो, तो झलक को लेटरबॉक्स करने के लिए, स्केल टाइप को FIT_CENTER पर सेट करें

ज़्यादा जानकारी के लिए, CameraX के दस्तावेज़ में झलक दिखाने की सुविधा लागू करना लेख पढ़ें.

दूसरा समाधान: CameraViewfinder 

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

ज़्यादा जानकारी के लिए, कैमरा व्यूफ़ाइंडर की सुविधा के बारे में जानकारी ब्लॉग पोस्ट और कैमरा प्रीव्यू डेवलपर गाइड देखें.

तीसरा समाधान: Camera2 को मैन्युअल तरीके से लागू करना 

अगर CameraX या CameraViewfinder का इस्तेमाल नहीं किया जा सकता, तो आपको ओरिएंटेशन और आसपेक्ट रेशियो का हिसाब मैन्युअल तरीके से लगाना होगा. साथ ही, यह पक्का करना होगा कि कॉन्फ़िगरेशन में हर बदलाव के साथ, हिसाब अपडेट हो जाए:

• CameraCharacteristics से कैमरे के सेंसर का ओरिएंटेशन (उदाहरण के लिए, 0, 90, 180, 270 डिग्री) पाएं
• डिवाइस के डिसप्ले का मौजूदा रोटेशन (उदाहरण के लिए, 0, 90, 180, 270 डिग्री) पाएं
• कैमरा सेंसर के ओरिएंटेशन और डिसप्ले रोटेशन की वैल्यू का इस्तेमाल करके, अपने SurfaceView या TextureView के लिए ज़रूरी बदलावों का पता लगाएं
• यह पक्का करें कि आपके आउटपुट Surface का आसपेक्ट रेशियो, कैमरे की झलक के आसपेक्ट रेशियो से मेल खाता हो, ताकि इमेज में कोई गड़बड़ी न हो

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

ज़्यादा जानकारी के लिए, डेवलपर के लिए बनी कैमरे की झलक गाइड और अलग-अलग फ़ॉर्म फ़ैक्टर पर आपका Camera ऐप्लिकेशन वीडियो देखें.

चौथा समाधान: इंटेंट का इस्तेमाल करके, कैमरे से जुड़ी बुनियादी कार्रवाइयां करना 

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

ज़्यादा जानकारी के लिए, कैमरा इंटेंट देखें.

यूज़र इंटरफ़ेस (यूआई) को स्ट्रेच करने या बटन को ऐक्सेस न करने से बचें

अगर आपका ऐप्लिकेशन किसी खास डिवाइस ओरिएंटेशन या डिसप्ले के आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) के हिसाब से काम करता है, तो अलग-अलग ओरिएंटेशन या विंडो साइज़ में ऐप्लिकेशन का इस्तेमाल करने पर समस्याएं आ सकती हैं.

पक्का करें कि बड़ी स्क्रीन पर बटन, टेक्स्ट फ़ील्ड, और अन्य एलिमेंट स्ट्रेच न हों.

आपने शायद बटन, टेक्स्ट फ़ील्ड, और कार्ड को fillMaxWidth या match_parent पर सेट किया हो.  फ़ोन पर यह बहुत अच्छा दिखता है. हालांकि, टैबलेट या फ़ोल्ड किए जा सकने वाले डिवाइस को लैंडस्केप मोड में रखने पर, यूज़र इंटरफ़ेस (यूआई) एलिमेंट पूरी बड़ी स्क्रीन पर फैल जाते हैं. Jetpack Compose में, widthIn मॉडिफ़ायर का इस्तेमाल करके, कॉम्पोनेंट के लिए ज़्यादा से ज़्यादा चौड़ाई सेट की जा सकती है. इससे कॉन्टेंट को स्ट्रेच होने से रोका जा सकता है:

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

अगर कोई व्यक्ति फ़ोल्ड किए जा सकने वाले डिवाइस या टैबलेट पर, लैंडस्केप मोड में आपका ऐप्लिकेशन खोलता है, तो स्क्रीन के सबसे नीचे मौजूद ऐक्शन बटन, जैसे कि सेव करें या लॉगिन करें, स्क्रीन पर नहीं दिख सकते. अगर कंटेनर को स्क्रोल नहीं किया जा सकता है, तो उपयोगकर्ता को आगे बढ़ने से रोका जा सकता है. Jetpack Compose में, अपने कॉम्पोनेंट में verticalScroll मॉडिफ़ायर जोड़ा जा सकता है:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

ज़्यादा से ज़्यादा चौड़ाई की सीमाओं को वर्टिकल स्क्रोलिंग के साथ मिलाकर, यह पक्का किया जा सकता है कि ऐप्लिकेशन काम करता रहे और इस्तेमाल किया जा सके. भले ही, ऐप्लिकेशन की विंडो का साइज़ कितना भी बड़ा या छोटा हो.

अडैप्टिव लेआउट बनाने के बारे में हमारी गाइड देखें.

कॉन्फ़िगरेशन में बदलाव होने पर भी स्थिति को बनाए रखना

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

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

यूज़र इंटरफ़ेस (यूआई) की स्थिति सेव करने के बारे में हमारी गाइड देखें.

अगस्त 2027 तक, एपीआई लेवल 37 को टारगेट करना

अगर आपके ऐप्लिकेशन ने एपीआई लेवल 36 को टारगेट करते समय, इन बदलावों से ऑप्ट आउट किया था, तो आपके ऐप्लिकेशन पर Android 17 के ऑप्ट-आउट को हटाने का असर तब तक नहीं पड़ेगा, जब तक आपका ऐप्लिकेशन एपीआई लेवल 37 को टारगेट नहीं करता. हम आपको पहले से ही इन बदलावों के बारे में बता रहे हैं, ताकि आप अपने ऐप्लिकेशन में ज़रूरी बदलाव कर सकें. ये बदलाव इस समयसीमा के दौरान लागू होंगे:

• Android 17: ऊपर बताए गए बदलाव, बड़ी स्क्रीन वाले डिवाइसों (स्क्रीन की सबसे कम चौड़ाई > 600 dp) के लिए, एपीआई लेवल 37 को टारगेट करने वाले ऐप्लिकेशन के लिए डिफ़ॉल्ट अनुभव होगा. डेवलपर के पास, इससे ऑप्ट-आउट करने का विकल्प नहीं होगा.

किसी खास एपीआई लेवल को टारगेट करने की समयसीमाएं, ऐप्लिकेशन स्टोर के हिसाब से अलग-अलग होती हैं. Google Play पर सबमिट किए जाने वाले नए ऐप्लिकेशन और अपडेट को, एपीआई लेवल 37 को टारगेट करना होगा. इसलिए, अगस्त 2027 से इस सुविधा का इस्तेमाल करना ज़रूरी होगा.

Android 17 के लिए तैयारी करना

Android 17 में ऐप्लिकेशन पर असर डालने वाले सभी बदलावों के लिए, Android 17 में हुए बदलावों के बारे में जानकारी देने वाला पेज देखें. अपने ऐप्लिकेशन की जांच करने के लिए, Android 17 का बीटा 1 वर्शन डाउनलोड करें और targetSdkPreview = “CinnamonBun” पर अपडेट करें. इसके अलावा, ऐप्लिकेशन के साथ काम करने वाले फ़्रेमवर्क का इस्तेमाल करके, कुछ बदलावों को चालू करें.

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

इंतज़ार न करें. आज से ही Android 17 के लिए तैयार हो जाएं!