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

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

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

और पढ़ें →

从历史上看，Android 仅支持 4 KB 内存页面大小，这优化了系统内存性能，以适应 Android 设备通常拥有的平均总内存量。从 Android 15 开始，AOSP 支持配置为使用 16 KB 页面大小的设备（16 KB 设备）。如果您的应用直接或通过 SDK 间接使用任何 NDK 库，则需要重新构建应用，才能在这些 16 KB 设备上运行。

随着设备制造商不断制造出具有更大物理内存 (RAM) 的设备，许多此类设备将采用 16 KB（最终甚至更大）的页面大小来优化设备性能。添加对 16 KB 页面大小设备的支持，可让您的应用在这些设备上运行，并帮助您的应用受益于相关的性能改进。如果不重新编译，应用将无法在未来 Android 版本的 16 KB 设备上运行。

为帮助您为应用添加支持，我们提供了相关指南，介绍了如何检查应用是否受到影响、如何重新构建应用（如果适用），以及如何使用模拟器（包括 Android 模拟器的 Android 15 系统映像）在 16 KB 环境中测试应用。

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

配置为使用 16 KB 页面大小的设备平均会使用略多一些的内存，但系统和应用的性能也会得到各种提升：

• 缩短了系统内存压力时的应用启动时间：平均降低了 3.16%；对于我们测试的某些应用而言，改进幅度更大（最高可达 30%）
• 应用启动期间的功耗降低：平均降低了 4.56%
• 相机启动更快：热启动速度平均提高了 4.48%，冷启动速度平均提高了 6.60%
• 缩短了系统启动时间：平均缩短了 8%（约 950 毫秒）

这些改进基于我们的初始测试，实际设备上的结果可能会有所不同。随着测试的继续进行，我们将进一步分析应用的潜在收益。

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

如果您的应用使用了任何原生代码，则应重新构建应用，使其支持 16 KB 设备。如果您不确定自己的应用是否使用了原生代码，可以使用 APK 分析器来确定是否存在任何原生代码，然后检查您找到的任何共享库的 ELF 段对齐情况。Android Studio 还提供了一些功能，可帮助您自动检测对齐问题。

如果您的应用仅使用以 Java 或 Kotlin 编程语言编写的代码（包括所有库或 SDK），则该应用已支持 16 KB 设备。不过，我们建议您在 16 KB 环境中测试应用，以验证应用行为是否出现意外的回归。

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

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

• आपका ऐप्लिकेशन, 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 या इससे नया और NDK वर्शन r28 या इससे नया) पर अपडेट किया है और 16 केबी के साथ काम करने वाली पहले से बनी डिपेंडेंसी का इस्तेमाल किया है, तो आपका ऐप्लिकेशन डिफ़ॉल्ट रूप से 16 केबी के साथ काम करेगा. साथ ही, कोड ठीक करने और रनटाइम की समस्याओं को हल करने वाले चरण को छोड़ा जा सकता है.

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

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

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

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

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

ध्यान दें: AGP टूल के 8.3 से 8.5 वर्शन में, ऐप्लिकेशन डिफ़ॉल्ट रूप से 16 केबी अलाइन होते हैं. हालांकि, bundletool डिफ़ॉल्ट रूप से APK को zipalign नहीं करता. इसलिए, ऐसा हो सकता है कि ऐप्लिकेशन काम कर रहा हो, लेकिन Play में बंडल से बनाए जाने पर वह इंस्टॉल न हो.

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

Groovy

अपनी build.gradle फ़ाइल में, यह विकल्प जोड़ें:

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

Kotlin

अपनी build.gradle.kts फ़ाइल में, यह विकल्प जोड़ें:

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

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

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

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

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

ध्यान दें: अगर आपका ऐप्लिकेशन, फ़ाइल सिस्टम में नेटिव लाइब्रेरी को एक्सट्रैक्ट नहीं करता है (extractNativeLibs को false पर सेट किया गया है), तो आपको 16 केबी ईएलएफ़ अलाइनमेंट का इस्तेमाल करके कंपाइल करने के बाद, अपने ऐप्लिकेशन के बाइनरी साइज़ में थोड़ी बढ़ोतरी दिख सकती है. Android 15 में पैकेज मैनेजर को ऑप्टिमाइज़ करने से, इस बढ़ोतरी की वजह से रनटाइम की लागत कम हो जाती है.

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

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

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

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

Android NDK r27

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

ndk-build

आपके Application.mk में:

APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true

Groovy

अपनी build.gradle फ़ाइल में, आर्ग्युमेंट सेट करें -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 "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
      }
    }
  }
}

Kotlin

अपनी build.gradle.kts फ़ाइल में, आर्ग्युमेंट सेट करें -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 कॉन्फ़िगरेशन को इस तरह अपडेट करना होगा:

ndk-build

16 केबी ईएलएफ़ अलाइनमेंट चालू करने के लिए, अपना Android.mk अपडेट करें:

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

CMake

16 केबी ईएलएफ़ अलाइनमेंट चालू करने के लिए, अपना CMakeLists.txt अपडेट करें:

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 कॉन्फ़िगरेशन को इस तरह अपडेट करें:

ndk-build

16 केबी वाले पेज साइज़ के साथ काम करने वाला ईएलएफ़ बनाने के लिए, अपना Android.mk अपडेट करें:

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

CMake

16 केबी वाले पेज साइज़ के साथ काम करने वाला ईएलएफ़ बनाने के लिए, अपना CMakeLists.txt अपडेट करें:

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")

अहम जानकारी: भले ही आपका ऐप्लिकेशन, NDKs r26 और उससे पहले के वर्शन की C++ स्टैंडर्ड लाइब्रेरी (libc++_shared.so) से डाइनैमिक तौर पर लिंक हो, जिनमें से कुछ 16 केबी के अलाइन नहीं हैं, फिर भी आपको यहां मौजूद अन्य सभी लाइब्रेरी का अलाइनमेंट अपडेट करना चाहिए. साथ ही, PAGE_SIZE पर निर्भर न रहने के लिए, आपको अपना कोड अपडेट करना चाहिए. 16 केबी वाले डिवाइसों पर, NDK टूल के उन पुराने वर्शन को टेस्ट करने के लिए, Android CI पर LTS NDK टूल के r23 और r25 वर्शन की कैनरी रिलीज़ उपलब्ध हैं. इनमें 16 केबी के हिसाब से अलाइन की गई libc++_shared.so लाइब्रेरी शामिल हैं. इसके बावजूद, हमारा सुझाव है कि C++ स्टैंडर्ड लाइब्रेरी के 16 केबी ELF अलाइन किए गए वर्शन पर अपडेट करने के लिए, Android NDK r27 या इसके बाद के वर्शन पर जाएं. ऐसा न करने पर, आपका ऐप्लिकेशन आज 16 केबी वाले डिवाइसों पर इंस्टॉल नहीं हो पाएगा.

अगर आपके पास नए Android NDK पर स्विच करने का विकल्प नहीं है, तो हो सकता है कि आप अपने ऐप्लिकेशन को अपडेट करके, C++ स्टैंडर्ड लाइब्रेरी को अपनी शेयर की गई लाइब्रेरी में स्टैटिक तौर पर कंपाइल कर सकें. C++ स्टैंडर्ड लाइब्रेरी को स्टैटिक तौर पर लिंक करने के बारे में जानकारी पाने के लिए, C++ लाइब्रेरी सहायता सेक्शन देखें. साथ ही, अहम बातें सेक्शन को ज़रूर पढ़ें.

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

भले ही, आपका ऐप्लिकेशन 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 एम्युलेटर सेट अप करना

अहम जानकारी: एक समस्या है, जिसकी वजह से 16 केबी की इम्युलेटर सिस्टम इमेज के साथ LLDB की मदद से डीबग नहीं किया जा सकता. इस समस्या को ठीक करने के लिए, NDK r27 RC 1 और Android Studio Koala Feature Drop | 2024.1.2 Canary 5 में सुधार किया गया है.

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 सिस्टम की इमेज
   ध्यान दें: अगर आपको काम करने वाले Google Pixel डिवाइस को एमुलेट करना है, तो आपको सिर्फ़ ARM 64 v8a सिस्टम इमेज की ज़रूरत होगी.

   

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 KB 模式

切换以 16KB 页面大小启动设备开发者选项，以在 16 KB 模式下启动设备。

从 Android 15 QPR1 开始，您可以使用某些设备上提供的开发者选项，以 16 KB 模式启动设备并执行设备端测试。在使用开发者选项之前，请依次前往设置 > 系统 > 软件更新，并应用所有可用的更新。

此开发者选项适用于以下设备：

• 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 或更高版本）

ध्यान दें: Android 15 QPR2, बीटा वर्शन में है. ज़रूरी शर्तें पूरी करने वाले डिवाइस पर QPR2 पाने के बारे में ज़्यादा जानने के लिए, Android 15 QPR बीटा वर्शन पाना लेख पढ़ें.

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

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

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