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 मिलीसेकंड) की बढ़ोतरी हुई

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

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

अगर आपका ऐप्लिकेशन किसी नेटिव कोड का इस्तेमाल करता है, तो आपको अपने ऐप्लिकेशन को 16 केबी वाले डिवाइसों के लिए फिर से बनाना होगा. अगर आपको नहीं पता कि आपका ऐप्लिकेशन नेटिव कोड का इस्तेमाल करता है या नहीं, तो APK विश्लेषक का इस्तेमाल करके यह पता लगाया जा सकता है कि कोई नेटिव कोड मौजूद है या नहीं. इसके बाद, आपको जो शेयर की गई लाइब्रेरी मिलती हैं उनके ELF सेगमेंट के अलाइनमेंट की जांच करें. Android Studio में ऐसी सुविधाएं भी होती हैं जिनकी मदद से, अलाइनमेंट से जुड़ी समस्याओं का पता अपने-आप चल जाता है.

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

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

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

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

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

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

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

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

   

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

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

   

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

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

Android Studio में Lint, उन नेटिव लाइब्रेरी को भी हाइलाइट करता है जो 16 केबी वाले पेज साइज़ के साथ अलाइन नहीं हैं.

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

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

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

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

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

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

   check_elf_alignment.sh APK_NAME.apk
   

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

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

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

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

1. पक्का करें कि Android Studio में एसडीके मैनेजर या sdkmanager कमांड-लाइन टूल का इस्तेमाल करके, Android SDK बिल्ड-टूल का 35.0.0 या इसके बाद वाला वर्शन और the 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 Analyzer का इस्तेमाल करके, नेटिव लाइब्रेरी की पहचान करते समय दिखती हैं. शेयर किए गए हर ऑब्जेक्ट फ़ाइल पर यह निर्देश चलाएं:

   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 फ़ाइल का नाम है. अगर शेयर की गई सभी लाइब्रेरी सही तरीके से अलाइन की गई हैं, तो आउटपुट की आखिरी लाइन में "Verification successful" दिखेगा.

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

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

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

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

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

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

ज़िप अलाइनमेंट की पुष्टि करने के लिए, bundletool का इस्तेमाल करना

अपने बंडल का अलाइनमेंट देखने के लिए, इसका इस्तेमाल करें:

bundletool dump config --bundle=<my .aab>  | grep alignment

अगर आपको PAGE_ALIGNMENT_16K दिखता है, तो इसका मतलब है कि आपका बंडल, 16 केबी ज़िप अलाइनमेंट का अनुरोध करता है. अगर आपको PAGE_ALIGNMENT_4K दिखता है, तो इसका मतलब है कि इस AAB से बनाए गए APK में, ज़िप फ़ाइल में 4 केबी अलाइन की गई .so फ़ाइलें होंगी.

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

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

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

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

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

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

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

अगर AGP का 8.0 या इससे पहले वाला वर्शन इस्तेमाल किया जा रहा है, तो आपको अपनी gradle.properties फ़ाइल में, ऐप्लिकेशन बंडल के लिए कंप्रेस न की गई नेटिव लाइब्रेरी का विकल्प भी बंद करना होगा:

android.bundle.enableUncompressedNativeLibs=false

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

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

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

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

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

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

Android NDK का r27 और इससे पहले वाला वर्शन

Android NDK के r27 या इससे पहले वाले वर्शन के साथ, 16 केबी अलाइन की गई शेयर की गई लाइब्रेरी को कंपाइल करने के लिए, इन लिंकर फ़्लैग का इस्तेमाल करें:

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

अपने बिल्ड सिस्टम कॉन्फ़िगरेशन फ़ाइलों को अपडेट करने का तरीका यहां बताया गया है:

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

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    "-Wl,-z,max-page-size=16384"
    "-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 केबी वाले पेज साइज़ के साथ काम करते हैं या नहीं

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

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

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

1. Android 15 SDK या इसके बाद वाला वर्शन सेट अप करें.

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

   • Android 15 की सिस्टम इमेज के साथ, Android Emulator सेट अप करें. यह इमेज 16 केबी वाले पेज साइज़ पर आधारित है
     • ARM64 पर, 16 केबी वाले पेज साइज़ के साथ Cuttlefish का इस्तेमाल करना
     • x86-64 पर, 16 केबी वाले पेज साइज़ के साथ Cuttlefish को सिम्युलेट करना
   • डेवलपर के लिए सेटिंग और टूल का इस्तेमाल करके, किसी डिवाइस पर 16 केबी मोड चालू करना
   • 16 केबी वाले पेज साइज़ के साथ काम करने वाले डिवाइसों पर, Samsung Remote Test Lab का इस्तेमाल करना

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

   adb shell getconf PAGE_SIZE
   

   निर्देश से, 16384 वैल्यू मिलनी चाहिए.

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

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

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

16 केबी वाले पेज साइज़ पर आधारित सिस्टम इमेज के साथ, Android Emulator सेट अप करना

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

1. Android Studio में, टूल > एसडीके मैनेजर पर क्लिक करें.

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

   • Google APIs Experimental 16 KB Page Size ARM 64 v8a System Image
   • Google APIs Experimental 16 KB Page Size Intel x86_64 Atom System Image

   

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

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

   

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

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

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

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

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

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

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

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

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

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

16 केबी बैककम्पैट मोड

पेज साइज़ कंपैट मोड में चेतावनी

16 केबी बैककम्पैट विकल्प तब उपलब्ध होता है, जब कोई डिवाइस 16 केबी कर्नेल के साथ काम कर रहा हो. पैकेज मैनेजर, किसी ऐप्लिकेशन को 16 केबी बैककम्पैट मोड में तब चलाता है, जब ये शर्तें पूरी होती हैं:

• अगर ऐप्लिकेशन में ईएलएफ़ फ़ाइलें (जिनका एक्सटेंशन .so है) मौजूद हैं और उनका लोड सेगमेंट अलाइनमेंट 4 केबी है.
• अगर ज़िप किए गए APK में, कंप्रेस न की गई ईएलएफ़ फ़ाइलें मौजूद हैं जो 4 केबी ज़िप अलाइन हैं.

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

16 केबी बैककम्पैट मोड की मदद से, कुछ ऐप्लिकेशन काम कर सकते हैं. हालांकि, बेहतर भरोसेमंद और स्थिर परफ़ॉर्मेंस के लिए, ऐप्लिकेशन को 16 केबी अलाइन होना चाहिए.

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

पेज साइज़ कंपैट मोड की सेटिंग

डिवाइस पर मौजूद हर ऐप्लिकेशन के लिए, 16 केबी बैककम्पैट मोड को ज़बरदस्ती चालू करने के लिए:

adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

डिवाइस पर मौजूद हर ऐप्लिकेशन के लिए, 16 केबी बैककम्पैट मोड को ज़बरदस्ती बंद करने के लिए:

adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

Android 17 में, हर ऐप्लिकेशन के लिए 16 केबी बैककम्पैट मोड को ज़बरदस्ती बंद किया जा सकता है. साथ ही, किसी भी ऐसे बाइनरी को तुरंत बंद किया जा सकता है जो 16 केबी वाले पेज साइज़ के साथ काम नहीं करता:

    adb shell setprop bionic.linker.16kb.app_compat.enabled fatal
    adb shell setprop pm.16kb.app_compat.disabled true

किसी खास ऐप्लिकेशन के AndroidManifest.xml में, android:pageSizeCompat प्रॉपर्टी को चालू या बंद पर सेट करके, बैककम्पैट मोड चालू या बंद करें. इस प्रॉपर्टी को सेट करने पर, ऐप्लिकेशन लॉन्च होने पर बैककम्पैट मोड की चेतावनियां नहीं दिखाएगा.

Google Play पर ऐप्लिकेशन के काम करने से जुड़ी ज़रूरी शर्त

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

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