16 केबी वाले पेज साइज़ का इस्तेमाल करें

Google Play पर 16 केबी वाले पेज साइज़ के साथ काम करने की ज़रूरी शर्तें

Google Play पर सबमिट किए गए सभी नए ऐप्लिकेशन और मौजूदा ऐप्लिकेशन के अपडेट, 1 नवंबर, 2025 से 64-बिट डिवाइसों पर 16 केबी के पेज साइज़ के साथ काम करने चाहिए. ये ऐप्लिकेशन, Android 15 और उसके बाद के वर्शन वाले डिवाइसों को टारगेट करते हों.

और पढ़ें →

Android पर, अब तक सिर्फ़ 4 केबी मेमोरी वाले पेज साइज़ का इस्तेमाल किया जा सकता था. इससे, Android डिवाइसों में आम तौर पर मौजूद कुल मेमोरी के लिए, सिस्टम मेमोरी की परफ़ॉर्मेंस को ऑप्टिमाइज़ किया जाता था. Android 15 से, AOSP उन डिवाइसों के साथ काम करता है जिन्हें 16 केबी (16 केबी डिवाइस) के पेज साइज़ का इस्तेमाल करने के लिए कॉन्फ़िगर किया गया है. अगर आपका ऐप्लिकेशन, सीधे तौर पर या किसी SDK टूल के ज़रिए, NDK लाइब्रेरी का इस्तेमाल करता है, तो आपको अपने ऐप्लिकेशन को फिर से बनाना होगा, ताकि वह 16 केबी वाले डिवाइसों पर काम कर सके.

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

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

फ़ायदे और परफ़ॉर्मेंस में होने वाली बढ़ोतरी

16 केबी वाले पेज साइज़ के साथ कॉन्फ़िगर किए गए डिवाइस औसतन थोड़ी ज़्यादा मेमोरी का इस्तेमाल करते हैं, लेकिन इससे सिस्टम और ऐप्लिकेशन, दोनों के लिए परफ़ॉर्मेंस में कई सुधार भी होते हैं:

• सिस्टम में मेमोरी कम होने पर, ऐप्लिकेशन लॉन्च होने में लगने वाला समय कम हो गया है: औसतन 3.16% कम, जिन ऐप्लिकेशन की हमने जांच की है उनमें 30% तक का सुधार हुआ है
• ऐप्लिकेशन के लॉन्च के दौरान, पावर सप्लाई में कमी: औसतन 4.56% की कमी
• कैमरे को तेज़ी से लॉन्च करने की सुविधा: औसतन 4.48% ज़्यादा तेज़ी से हॉट स्टार्ट और 6.60% ज़्यादा तेज़ी से कोल्ड स्टार्ट
• सिस्टम बूट होने का समय बेहतर हुआ: औसतन 8% (करीब 950 मिलीसेकंड) की बढ़ोतरी हुई

ये सुधार, हमारी शुरुआती जांच पर आधारित हैं. इसलिए, हो सकता है कि असल डिवाइसों पर नतीजे अलग हों. जैसे-जैसे हम अपनी टेस्टिंग को जारी रखेंगे, वैसे-वैसे हम ऐप्लिकेशन को मिलने वाले संभावित फ़ायदों का अतिरिक्त विश्लेषण देंगे.

देखें कि आपके ऐप्लिकेशन पर इसका असर पड़ा है या नहीं

If your app uses any native code, then you should rebuild your app with support for 16 KB devices. If you are unsure if your app uses native code, you can use the APK Analyzer to identify whether any native code is present and then check the alignment of ELF segments for any shared libraries that you find. Android Studio also provides features that help you to automatically detect alignment issues.

If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices. Nevertheless, we recommend that you test your app in a 16 KB environment to verify that there are no unexpected regressions in app behavior.

क्या आपका ऐप्लिकेशन, नेटिव कोड का इस्तेमाल करता है?

आपका ऐप्लिकेशन नेटिव कोड का इस्तेमाल तब करता है, जब इनमें से कोई भी शर्त पूरी होती है:

• आपका ऐप्लिकेशन, C/C++ (नेटिव) कोड का इस्तेमाल करता है. अगर आपका ऐप्लिकेशन Android NDK का इस्तेमाल करता है, तो इसका मतलब है कि आपका ऐप्लिकेशन नेटिव कोड का इस्तेमाल करता है.
• आपका ऐप्लिकेशन, तीसरे पक्ष की उन नेटिव लाइब्रेरी या डिपेंडेंसी (जैसे, SDK टूल) से लिंक होता है जो उनका इस्तेमाल करती हैं.
• आपका ऐप्लिकेशन, तीसरे पक्ष के किसी ऐप्लिकेशन बिल्डर ने बनाया है. यह ऐप्लिकेशन, डिवाइस पर नेटिव लाइब्रेरी का इस्तेमाल करता है.

APK ऐनालाइज़र का इस्तेमाल करके नेटिव लाइब्रेरी की पहचान करना

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

1. Android Studio खोलें. इसके बाद, फ़ाइल > खोलें पर क्लिक करें और कोई भी प्रोजेक्ट चुनें.

2. मेन्यू बार में, बिल्ड > APK का विश्लेषण करें... पर क्लिक करें

   

3. वह APK चुनें जिसका आपको विश्लेषण करना है.

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

   

अपने-आप होने वाली जांचों की मदद से, अलाइनमेंट से जुड़ी समस्याओं का पता लगाना

अगर आपकी पहले से बनी लाइब्रेरी या APK, 16 KB के मुताबिक नहीं हैं, तो Android Studio आपको इसकी पहले से चेतावनी दे देता है. APK विश्लेषक टूल का इस्तेमाल करके, यह देखें कि किन लाइब्रेरी को अपडेट करने की ज़रूरत है या कोड में कोई बदलाव करना ज़रूरी है या नहीं.

Android Studio में मौजूद Lint टूल, उन नेटिव लाइब्रेरी को भी हाइलाइट करता है जो 16 केबी के अलाइनमेंट के मुताबिक नहीं हैं.

शेयर की गई लाइब्रेरी के लिए ईएलएफ़ सेगमेंट के अलाइनमेंट की जांच करना

किसी भी शेयर की गई लाइब्रेरी के लिए, पुष्टि करें कि शेयर की गई लाइब्रेरी के ELF सेगमेंट, 16 केबी ELF अलाइनमेंट का इस्तेमाल करके सही तरीके से अलाइन किए गए हैं. अगर Linux या macOS पर डेवलप किया जा रहा है, तो नीचे दिए गए सेक्शन में बताए गए तरीके से check_elf_alignment.sh स्क्रिप्ट का इस्तेमाल किया जा सकता है. कमांड-लाइन टूल का सीधे इस्तेमाल भी किया जा सकता है.

check_elf_alignment.sh स्क्रिप्ट (Linux या macOS) का इस्तेमाल करना

check_elf_alignment.sh स्क्रिप्ट का इस्तेमाल करके, ELF सेगमेंट के अलाइनमेंट की जांच करने के लिए, यह तरीका अपनाएं:

1. check_elf_alignment.sh स्क्रिप्ट को किसी फ़ाइल में सेव करें.

2. अपने ऐप्लिकेशन की APK फ़ाइल पर स्क्रिप्ट चलाएं:

   check_elf_alignment.sh APK_NAME.apk
   

   स्क्रिप्ट, सभी arm64-v8a शेयर की गई लाइब्रेरी के लिए ALIGNED या UNALIGNED दिखाती है.

3. अगर शेयर की गई कोई arm64-v8a या x86_64 लाइब्रेरी UNALIGNED है, तो आपको उन लाइब्रेरी के लिए पैकेजिंग अपडेट करनी होगी. इसके बाद, अपने ऐप्लिकेशन को फिर से कंपाइल करें और इस सेक्शन में दिए गए निर्देशों का पालन करके फिर से जांच करें.

कमांड-लाइन टूल का सीधे तौर पर इस्तेमाल करना

सीधे कमांड-लाइन टूल का इस्तेमाल करके, ELF सेगमेंट के अलाइनमेंट की जांच करने के लिए, यह तरीका अपनाएं:

1. पक्का करें कि Android Studio में SDK मैनेजर या sdkmanager कमांड-लाइन टूल का इस्तेमाल करके, Android SDK Build-Tools का 35.0.0 या इसके बाद का वर्शन और Android NDK, दोनों इंस्टॉल किए गए हों.

2. अपने ऐप्लिकेशन की APK फ़ाइल को निकालने के लिए:

   Linux या macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. APK फ़ाइल को जिस अस्थायी डायरेक्ट्री में निकाला गया है उसमें, शेयर किए गए ऑब्जेक्ट (.so) फ़ाइलों के लिए lib डायरेक्ट्री के कॉन्टेंट की जांच करें. ये वही शेयर की गई ऑब्जेक्ट फ़ाइलें हैं जो आपको APK विश्लेषक का इस्तेमाल करके नेटिव लाइब्रेरी की पहचान करने के दौरान दिखी होंगी. हर शेयर की गई ऑब्जेक्ट फ़ाइल पर यह कमांड चलाएं:

   Linux या macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   यहां SDK_ROOT_LOCATION, उस डायरेक्ट्री का पाथ है जहां आपने Android SDK टूल इंस्टॉल किया है, SHARED_OBJECT_FILE उस शेयर की गई ऑब्जेक्ट फ़ाइल का नाम है जिसकी जांच की जा रही है, और NDK_VERSION, आपके इंस्टॉल किए गए Android NDK टूल का वर्शन है (उदाहरण के लिए, 28.0.12433566). जांच की गई हर फ़ाइल के लिए, आउटपुट कुछ ऐसा दिखेगा:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. आउटपुट लाइन की जांच करके पक्का करें कि लोड सेगमेंट की वैल्यू, 2**14 से कम न हों. अगर किसी लोड सेगमेंट की वैल्यू 2**13, 2**12 या इससे कम है, तो आपको उन लाइब्रेरी के लिए पैकेजिंग अपडेट करनी होगी. इसके बाद, अपने ऐप्लिकेशन को फिर से कंपाइल करें और इस सेक्शन में दिए गए निर्देशों का पालन करके फिर से जांच करें.

5. इसके बाद, अपने ऐप्लिकेशन की APK फ़ाइल पर zipalign कमांड-लाइन टूल चलाएं:

   Linux या macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   यहां SDK_ROOT_LOCATION, उस डायरेक्ट्री का पाथ है जहां आपने Android SDK टूल इंस्टॉल किया है और APK_NAME, आपके ऐप्लिकेशन की APK फ़ाइल का नाम है. अगर सभी शेयर की गई लाइब्रेरी सही तरीके से अलाइन की गई हैं, तो आउटपुट की आखिरी लाइन में "पुष्टि हो गई" दिखेगा.

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

16 केबी वाले डिवाइसों के लिए, अपने ऐप्लिकेशन को बिल्ड करना

अगर आपका ऐप्लिकेशन नेटिव कोड का इस्तेमाल करता है, तो नीचे दिए गए सेक्शन में बताए गए तरीके अपनाएं. इससे यह पक्का किया जा सकेगा कि आपका ऐप्लिकेशन 16 केबी वाले डिवाइसों पर काम करता है:

1. शेयर की गई लाइब्रेरी का पैकेज अपडेट करना
2. 16 केबी ईएलएफ़ अलाइनमेंट का इस्तेमाल करके, अपने ऐप्लिकेशन को कंपाइल करना
3. कोड ठीक करना और रनटाइम से जुड़ी समस्याएं हल करना
4. 16 केबी वाले पेज साइज़ के साथ काम करने वाले एसडीके टूल देखना

शेयर की गई लाइब्रेरी की पैकेजिंग अपडेट करना

हमारा सुझाव है कि आप AGP के 8.5.1 या इसके बाद के वर्शन पर अपग्रेड करें और बिना कंप्रेस की गई शेयर की गई लाइब्रेरी का इस्तेमाल करें.

AGP का 8.5.1 या इसके बाद का वर्शन

16 केबी वाले डिवाइसों पर, ऐसे ऐप्लिकेशन काम नहीं करते जो बिना कंप्रेस की गई शेयर की गई लाइब्रेरी के साथ शिप होते हैं. इन ऐप्लिकेशन को 16 केबी वाले ज़िप-अलाइन किए गए बाउंड्री पर अलाइन करना ज़रूरी है. ऐसा करने के लिए, आपको Android Gradle प्लग इन (AGP) के 8.5.1 या इसके बाद के वर्शन पर अपग्रेड करना होगा. अपग्रेड की प्रोसेस के बारे में जानने के लिए, Android Gradle प्लगिन अपग्रेड असिस्टेंट सेक्शन देखें.

AGP का 8.5 या इससे पहले का वर्शन

अगर AGP को 8.5.1 या इसके बाद के वर्शन पर अपग्रेड नहीं किया जा सकता, तो इसके बजाय, कंप्रेस की गई शेयर की गई लाइब्रेरी का इस्तेमाल करें. अपने Gradle कॉन्फ़िगरेशन को अपडेट करें, ताकि Gradle आपके ऐप्लिकेशन को पैकेज करते समय, शेयर की गई लाइब्रेरी को कंप्रेस कर सके. इससे, अलाइन न की गई शेयर की गई लाइब्रेरी की वजह से, ऐप्लिकेशन इंस्टॉल करने से जुड़ी समस्याओं से बचा जा सकता है.

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

16 केबी ईएलएफ़ अलाइनमेंट का इस्तेमाल करके, अपने ऐप्लिकेशन को कंपाइल करना

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

गेम डेवलपर के लिए, अगर आपका गेम Unity गेम इंजन पर चलता है, तो Unity गाइड देखें. अगर आपका गेम Unreal गेम इंजन पर चलता है, तो Unreal गाइड देखें. नेटिव गेम इंजन के लिए, इस गाइड को पढ़ें.

16 केबी ELF अलाइनमेंट का इस्तेमाल करके अपने ऐप्लिकेशन को कंपाइल करने के लिए, यहां दिए गए किसी एक सेक्शन में दिया गया तरीका अपनाएं. यह तरीका, इस्तेमाल किए जा रहे Android NDK के वर्शन के हिसाब से अलग-अलग हो सकता है.

Android NDK r28 और उसके बाद के वर्शन

NDK का r28 और उसके बाद के वर्शन, डिफ़ॉल्ट रूप से 16 केबी वाले अलाइनमेंट को कंपाइल करते हैं.

Android NDK r27

Android NDK के वर्शन r27 और उसके बाद के वर्शन के साथ, 16 केबी के अलाइन किए गए शेयर की गई लाइब्रेरी को कंपाइल करने के लिए, आपको अपने ndk-build, build.gradle, build.gradle.kts या लिंकर फ़्लैग को इस तरह अपडेट करना होगा:

APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
      }
    }
  }
}

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments += listOf("-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON")
      }
    }
  }
}

-Wl,-z,max-page-size=16384

Android NDK r26 और उससे पहले के वर्शन

Android NDK के r26 या इससे पहले के वर्शन के साथ, 16 केबी वाले पेज साइज़ के मुताबिक अलाइन की गई शेयर की गई लाइब्रेरी को कंपाइल करने के लिए, आपको अपने ndk-build या cmake कॉन्फ़िगरेशन को इस तरह अपडेट करना होगा:

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")

Android NDK r22 और उससे पहले के वर्शन

NDK r26 और इससे पहले के वर्शन के लिए बताए गए चरण के अलावा, अगर NDK r22 या इससे पहले के वर्शन का इस्तेमाल किया जा रहा है, तो आपको common-page-size=16384 सेट करना होगा. GNU ld और LLVM lld लिंकर के पुराने वर्शन में बग की वजह से, common-page-size=16384 सेटिंग करना ज़रूरी है. हालांकि, हमारा सुझाव है कि इन गड़बड़ियों से पूरी तरह से बचने के लिए, आप अपनी टूलकिट को नए वर्शन पर अपडेट करें.

Android NDK के r22 या इससे पहले के वर्शन के साथ, 16 केबी के पेज साइज़ वाली शेयर की जा सकने वाली लाइब्रेरी कंपाइल करने के लिए, अपने ndk-build या cmake कॉन्फ़िगरेशन को इस तरह अपडेट करें:

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"
LOCAL_LDFLAGS += "-Wl,-z,common-page-size=16384"

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")
target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,common-page-size=16384")

कोड ठीक करना और रनटाइम से जुड़ी समस्याएं हल करना

भले ही, आपका ऐप्लिकेशन 16 केबी के हिसाब से अलाइन किया गया हो, लेकिन अगर आपके कोड में कहीं यह अनुमान लगाया गया है कि डिवाइस में किसी खास साइज़ का पेज इस्तेमाल किया जा रहा है, तो आपके ऐप्लिकेशन में गड़बड़ियां हो सकती हैं. इससे बचने के लिए, यह तरीका अपनाएं:

1. कोड लॉजिक में, PAGE_SIZE के लिए हार्ड कोड की गई सभी डिपेंडेंसी हटाएं. इसके अलावा, ऐसे इंस्टेंस भी हटाएं जो यह मानते हैं कि किसी डिवाइस का पेज साइज़ 4 केबी (4096) है.

   इसके बजाय, getpagesize() या sysconf(_SC_PAGESIZE) का इस्तेमाल करें.

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

कुछ मामलों में, अगर आपका ऐप्लिकेशन PAGE_SIZE का इस्तेमाल ऐसी सुविधाजनक वैल्यू के तौर पर करता है जो पेज साइज़ से जुड़ी नहीं है, तो 16 केबी मोड में इस्तेमाल करने पर आपका ऐप्लिकेशन क्रैश नहीं होगा. हालांकि, अगर इस वैल्यू को MAP_FIXED के बिना mmap के साथ कर्नेल को पास किया जाता है, तो भी कर्नेल पूरे पेज का इस्तेमाल करता है. इससे कुछ मेमोरी बर्बाद होती है. इन वजहों से, NDK r27 और उसके बाद के वर्शन पर 16 केबी मोड चालू होने पर, PAGE_SIZE की वैल्यू तय नहीं की जाती.

अगर आपका ऐप्लिकेशन इस तरह से PAGE_SIZE का इस्तेमाल करता है और इस वैल्यू को सीधे कभी भी कर्नेल को पास नहीं करता है, तो PAGE_SIZE का इस्तेमाल करने के बजाय, एक नए नाम के साथ एक नया वैरिएबल बनाएं. इससे यह पता चलता है कि इसका इस्तेमाल अन्य कामों के लिए किया जाता है और यह असल मेमोरी पेज को नहीं दिखाता.

16 केबी वाले पेज साइज़ के साथ काम करने वाले एसडीके टूल देखना

कई SDK टूल, 16 केबी के पेज साइज़ के साथ काम करते हैं. खास तौर पर, अगर आपने उन्हें खुद बनाया है या हाल ही में बनाए गए टूल इस्तेमाल किए जा रहे हैं. हालांकि, कुछ पहले से बने SDK टूल या SDK टूल के वर्शन, 16 केबी के साथ काम नहीं करते. इसलिए, आपको SDK टूल की सेवा देने वाली हर कंपनी की वेबसाइट पर जाकर यह पता करना चाहिए कि 16 केबी के साथ किस वर्शन का इस्तेमाल किया जा सकता है.

अपने ऐप्लिकेशन को 16 केबी वाले एनवायरमेंट में टेस्ट करना

16 केबी वाले डिवाइसों के लिए अपना ऐप्लिकेशन बनाने के बाद, आपको 16 केबी वाले एनवायरमेंट में अपने ऐप्लिकेशन की जांच करनी होगी. इससे यह पता चलेगा कि आपके ऐप्लिकेशन में कोई समस्या है या नहीं. ऐसा करने के लिए, इन चरणों का अनुसरण करें:

1. Android 15 SDK टूल सेट अप करें.

2. टेस्टिंग के लिए इनमें से कोई एक एनवायरमेंट सेट अप करें:

   • 16 केबी वाले Android 15 सिस्टम इमेज के साथ Android एमुलेटर सेट अप करना
     • ARM64 पर 16 केबी वाले पेज साइज़ के साथ Cuttlefish का इस्तेमाल करना
     • x86-64 पर 16 केबी वाले पेज साइज़ के साथ Cuttlefish को सिम्युलेट करना
   • डेवलपर के लिए उपलब्ध विकल्पों का इस्तेमाल करके, किसी डिवाइस पर 16 केबी मोड चालू करना

3. अपना टेस्ट डिवाइस चालू करें. इसके बाद, यह पुष्टि करने के लिए कि वह 16 केबी एनवायरमेंट का इस्तेमाल कर रहा है, यह कमांड चलाएं:

   adb shell getconf PAGE_SIZE
   

   इस कमांड से 16384 वैल्यू मिलनी चाहिए.

4. यह पुष्टि करने के लिए कि आपका ऐप्लिकेशन 16 केबी के हिसाब से अलाइन है, यह zipalign कमांड चलाएं. यहां APK_NAME, आपके ऐप्लिकेशन की APK फ़ाइल का नाम है:

   zipalign -c -P 16 -v 4 APK_NAME.apk
   

5. अपने ऐप्लिकेशन की पूरी तरह से जांच करें. साथ ही, उन जगहों पर फ़ोकस करें जिन पर पेज के साइज़ का रेफ़रंस देने वाले कोड के इंस्टेंस में बदलाव का असर पड़ सकता है.

Android 15 की 16 केबी वाली सिस्टम इमेज की मदद से, Android एम्युलेटर सेट अप करना

Android एमुलेटर का इस्तेमाल करके 16 केबी का एनवायरमेंट सेट अप करने के लिए, यह तरीका अपनाएं:

1. 16 केबी वाली, Android 15 एमुलेटर सिस्टम इमेज, Android Studio Jellyfish | 2023.3.1 या इसके बाद के वर्शन के साथ काम करती हैं. हालांकि, 16 केबी वाले डिवाइसों के साथ काम करते समय बेहतर अनुभव पाने के लिए, Android Studio के Ladybug | 2024.2.1 या इसके बाद के वर्शन का इस्तेमाल करें.

   हम नई सुविधाओं पर लगातार काम कर रहे हैं. इसलिए, Android Studio के नए वर्शन या नए प्रीव्यू वर्शन के उपलब्ध होने पर, उन्हें डाउनलोड करें.

   याद रखें कि Android Studio के मौजूदा वर्शन को इंस्टॉल किया जा सकता है, क्योंकि एक साथ कई वर्शन इंस्टॉल किए जा सकते हैं.

2. Android Studio में, टूल > SDK मैनेजर पर क्लिक करें.

3. एसडीके प्लैटफ़ॉर्म टैब में, पैकेज की जानकारी दिखाएं को चुनें. इसके बाद, Android VanillaIceCream या इसके बाद के वर्शन वाले सेक्शन को बड़ा करें. इसके बाद, आपको जो वर्चुअल डिवाइस बनाने हैं उनके आधार पर, नीचे दी गई एमुलेटर सिस्टम इमेज में से एक या दोनों को चुनें:

   • Google APIs एक्सपेरिमेंटल 16 KB पेज साइज़ ARM 64 v8a सिस्टम इमेज
   • Google API एक्सपेरिमेंटल 16 केबी पेज साइज़ Intel x86_64 Atom सिस्टम की इमेज

   

4. आपने जो सिस्टम इमेज चुनी हैं उन्हें डाउनलोड करने के लिए, लागू करें > ठीक है पर क्लिक करें.

5. Android 15 के लिए वर्चुअल डिवाइस सेट अप करने का तरीका अपनाएं. इसके बाद, जब आपसे सिस्टम इमेज चुनने के लिए कहा जाए, तो 16 केबी की वह सिस्टम इमेज चुनें जिसे आपने डाउनलोड किया है. अगर यह अपने-आप सुझाई नहीं जाती है, तो अन्य इमेज टैब में 16 केबी की सिस्टम इमेज देखी जा सकती है.

   

कुछ एमुलेटर वर्शन और सिस्टम इमेज के लिए अतिरिक्त चरण

Android Emulator के 35.1.5 से 35.1.20 वर्शन के लिए, और SDK मैनेजर में उपलब्ध Android 15.0 16 केबी पेज साइज़ की सिस्टम इमेज के रिविज़न 4 से पहले, x86_64 सिस्टम पर 16 केबी वाले एनवायरमेंट को सिम्युलेट करने के लिए, आपको ये चरण भी पूरे करने होंगे. 35.1.21 वर्शन के बाद, और Android 15.0 16 केबी पेज साइज़ की सिस्टम इमेज के रिविज़न 4 या उसके बाद के वर्शन के लिए, यह तरीका अपनाने की ज़रूरत नहीं है.

1. डिवाइस मैनेजर में, 16 केबी वाली इमेज के बगल में मौजूद तीन बिंदुओं पर क्लिक करें. इसके बाद, डिस्क पर दिखाएं पर क्लिक करें.
2. इस फ़ोल्डर में, config.ini फ़ाइल ढूंढें.

3. config.ini फ़ाइल में यह लाइन जोड़ें और बदलाव सेव करें:

   kernel.parameters = androidboot.page_shift=14
   

4. अपने बदलावों की पुष्टि करने के लिए, यह कमांड चलाएं. इससे आपको 16384 दिखेगा:

   adb shell getconf PAGE_SIZE
   

एम्युलेटर लॉन्च करना

Android एमुलेटर और वर्चुअल डिवाइसों को सेट अप करने के बाद, टारगेट डिवाइस मेन्यू से या कमांड-लाइन से एमुलेटर लॉन्च करें.

डेवलपर के लिए उपलब्ध विकल्पों का इस्तेमाल करके, किसी डिवाइस पर 16 केबी मोड चालू करना

किसी डिवाइस को 16 केबी मोड में बूट करने के लिए, 16 केबी पेज साइज़ के साथ बूट करें डेवलपर विकल्प को टॉगल करें.

Android 15 QPR1 से, कुछ डिवाइसों पर उपलब्ध डेवलपर के विकल्प का इस्तेमाल करके, डिवाइस को 16 केबी मोड में बूट किया जा सकता है. साथ ही, डिवाइस पर टेस्टिंग की जा सकती है. डेवलपर के लिए उपलब्ध विकल्प का इस्तेमाल करने से पहले, सेटिंग > सिस्टम > सॉफ़्टवेयर अपडेट पर जाएं और उपलब्ध सभी अपडेट लागू करें.

डेवलपर के लिए यह विकल्प, इन डिवाइसों पर उपलब्ध है:

• Pixel 8 और 8 Pro (Android 15 QPR1 या इसके बाद के वर्शन पर काम करने वाले)

  चेतावनी: Android 15 QPR2 Beta 3 में एक समस्या है. इस वजह से, Pixel 8 डिवाइसों पर Android 15 QPR2 Beta 3 इंस्टॉल करने और डिवाइस को 16 KB मोड में बूट करने के बाद, टचस्क्रीन काम नहीं करती. इस समस्या का असर, Pixel 8 Pro डिवाइसों पर नहीं पड़ता.

• Pixel 8a (Android 15 QPR1 या इसके बाद के वर्शन के साथ)

  चेतावनी: Android 15 QPR2 Beta 3 में एक समस्या है. इस वजह से, Pixel 8a डिवाइसों पर Android 15 QPR2 Beta 3 इंस्टॉल करने और डिवाइस को 16 KB मोड में बूट करने के बाद, टचस्क्रीन काम नहीं करती.

• Pixel 9, 9 Pro, और 9 Pro XL (Android 15 QPR2 Beta 2 या इसके बाद के वर्शन पर काम करने वाले)

Google Play के साथ काम करने की ज़रूरी शर्तें

डिवाइस बनाने वाली कंपनियां, परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए डिवाइसों में ज़्यादा रैम देती हैं. इसलिए, कई डिवाइसों में 16 केबी जैसे बड़े पेज साइज़ का इस्तेमाल किया जाएगा. आने वाले समय में लॉन्च होने वाले इन डिवाइसों के लिए, Google Play ने काम करने से जुड़ी एक नई ज़रूरी शर्त लागू की है: 1 नवंबर, 2025 से, Google Play पर सबमिट किए जाने वाले सभी नए ऐप्लिकेशन और मौजूदा ऐप्लिकेशन के अपडेट, Android 15 (एपीआई लेवल 35) और इसके बाद के वर्शन पर काम करने वाले डिवाइसों को टारगेट करने चाहिए. साथ ही, इन ऐप्लिकेशन के पेज साइज़ 16 केबी होने चाहिए.

साथ काम करने की इस ज़रूरी शर्त के बारे में ज़्यादा जानने के लिए, यह ब्लॉग पोस्ट देखें.