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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

   

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

किसी भी शेयर की गई लाइब्रेरी के लिए, पुष्टि करें कि शेयर की गई लाइब्रेरी के ELF सेगमेंट, 16 KB 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 केबी ELF अलाइनमेंट का इस्तेमाल करके, अपने ऐप्लिकेशन को कंपाइल करना
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 केबी ELF अलाइनमेंट का इस्तेमाल करके, अपने ऐप्लिकेशन को कंपाइल करना

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

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

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

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

भले ही, आपका ऐप्लिकेशन 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 एमुलेटर सेट अप करना
   • डेवलपर के लिए उपलब्ध विकल्पों का इस्तेमाल करके, किसी डिवाइस पर 16 केबी मोड चालू करना
   • ARM64 पर 16 केबी वाले पेज साइज़ के साथ Cuttlefish का इस्तेमाल करना
   • x86-64 पर 16 केबी वाले पेज साइज़ के साथ Cuttlefish को सिम्युलेट करना

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 API एक्सपेरिमेंटल 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 या इसके बाद के वर्शन पर)