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

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

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

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

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

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

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

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

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

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

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

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

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

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

ज़्यादा जानकारी के लिए, Camera Viewfinder लॉन्च किया जा रहा है ब्लॉग पोस्ट और कैमरे की झलक डेवलपर गाइड देखें.

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

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

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

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

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

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

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