Android 过去仅支持 4 KB 内存页面大小, 优化了系统内存性能,以针对 Android 设备通常具备的功能。从 Android 15 开始,AOSP 支持 配置为使用 16 KB (16 KB) 页面大小的设备 设备)。如果您的应用使用任何 NDK 库,请直接使用 或者通过 SDK 间接创建,那么,您需要重新构建自己的应用 支持这些 16KB 设备。
随着设备制造商不断打造出 物理内存 (RAM),许多此类设备都会采用 16KB(以及 页面大小以优化设备的性能。正在添加 支持 16 KB 页面大小的设备,可使您的应用在这些设备上运行 并有助于您的应用从相关的广告效果中获益 改进。如果不重新编译,应用可能无法在 16KB 设备上运行 在未来的 Android 版本中正式推出。
为帮助您为应用添加支持,我们提供了有关如何检查 如果您的应用受到影响 重新构建您的应用(如果适用),以及如何在 Google Play 中 使用模拟器(包括 Android 15)的 16 KB 环境 系统映像)。
फ़ायदे और परफ़ॉर्मेंस में होने वाली बढ़ोतरी
配置为使用 16 KB 页面大小的设备平均会使用略多一些的内存,但系统和应用的性能也会得到各种提升:
- 缩短了系统内存压力时的应用启动时间:平均降低了 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 केबी के साथ काम करता है या नहीं):
- Android Studio खोलें. इसके बाद, फ़ाइल > खोलें पर क्लिक करें और कोई भी प्रोजेक्ट चुनें.
मेन्यू बार में, बिल्ड > APK का विश्लेषण करें... पर क्लिक करें
वह APK चुनें जिसका आपको विश्लेषण करना है.
lib
फ़ोल्डर में देखें. इसमें शेयर किए गए ऑब्जेक्ट (.so
) की फ़ाइलें हो सकती हैं. अगर कोई शेयर की गई ऑब्जेक्ट फ़ाइल मौजूद है, तो आपका ऐप्लिकेशन नेटिव कोड का इस्तेमाल करता है. अगर कोई शेयर की गई ऑब्जेक्ट फ़ाइल मौजूद नहीं है या कोईlib
फ़ोल्डर नहीं है, तो इसका मतलब है कि आपका ऐप्लिकेशन नेटिव कोड का इस्तेमाल नहीं करता.
शेयर की गई लाइब्रेरी के लिए ईएलएफ़ सेगमेंट के अलाइनमेंट की जांच करना
किसी भी शेयर की गई लाइब्रेरी के लिए, पुष्टि करें कि शेयर की गई लाइब्रेरी के ELF सेगमेंट, 16 केबी ELF अलाइनमेंट का इस्तेमाल करके सही तरीके से अलाइन किए गए हैं. अगर Linux या macOS पर डेवलप किया जा रहा है, तो नीचे दिए गए सेक्शन में बताए गए तरीके से check_elf_alignment.sh
स्क्रिप्ट का इस्तेमाल किया जा सकता है. कमांड-लाइन टूल का सीधे इस्तेमाल भी किया जा सकता है.
check_elf_alignment.sh स्क्रिप्ट (Linux या macOS) का इस्तेमाल करना
check_elf_alignment.sh
स्क्रिप्ट का इस्तेमाल करके, ELF सेगमेंट के अलाइनमेंट की जांच करने के लिए, यह तरीका अपनाएं:
check_elf_alignment.sh
स्क्रिप्ट को किसी फ़ाइल में सेव करें.अपने ऐप्लिकेशन की APK फ़ाइल पर स्क्रिप्ट चलाएं:
check_elf_alignment.sh APK_NAME.apk
स्क्रिप्ट, सभी
arm64-v8a
शेयर की गई लाइब्रेरी के लिएALIGNED
याUNALIGNED
दिखाती है.अगर शेयर की गई कोई
arm64-v8a
याx86_64
लाइब्रेरीUNALIGNED
है, तो आपको उन लाइब्रेरी के लिए पैकेजिंग अपडेट करनी होगी. इसके बाद, अपने ऐप्लिकेशन को फिर से कंपाइल करें और इस सेक्शन में दिए गए निर्देशों का पालन करके फिर से जांच करें.
कमांड-लाइन टूल का सीधे तौर पर इस्तेमाल करना
सीधे कमांड-लाइन टूल का इस्तेमाल करके, ELF सेगमेंट के अलाइनमेंट की जांच करने के लिए, यह तरीका अपनाएं:
- पक्का करें कि Android Studio में SDK मैनेजर या
sdkmanager
कमांड-लाइन टूल का इस्तेमाल करके, Android SDK Build-Tools का 35.0.0 या उसके बाद का वर्शन और Android NDK, दोनों इंस्टॉल किए गए हों. अपने ऐप्लिकेशन की 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
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
आउटपुट लाइन की जांच करके पक्का करें कि लोड सेगमेंट की वैल्यू,
2**14
से कम न हों. अगर किसी लोड सेगमेंट की वैल्यू2**13
,2**12
या इससे कम है, तो आपको उन लाइब्रेरी के लिए पैकेजिंग अपडेट करनी होगी. इसके बाद, अपने ऐप्लिकेशन को फिर से कंपाइल करें और इस सेक्शन में दिए गए निर्देशों का पालन करके फिर से जांच करें.इसके बाद, अपने ऐप्लिकेशन की 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 केबी वाले डिवाइसों पर काम करता है:
- शेयर की गई लाइब्रेरी का पैकेज अपडेट करना
- 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.5.1 या इसके बाद के वर्शन पर अपग्रेड नहीं किया जा सकता, तो इसके बजाय, कंप्रेस की गई शेयर की गई लाइब्रेरी का इस्तेमाल करें. अपने Gradle कॉन्फ़िगरेशन को अपडेट करें, ताकि Gradle आपके ऐप्लिकेशन को पैकेज करते समय, शेयर की गई लाइब्रेरी को कंप्रेस कर सके. इससे, अलाइन न की गई शेयर की गई लाइब्रेरी की वजह से, ऐप्लिकेशन इंस्टॉल करने से जुड़ी समस्याओं से बचा जा सकता है.
Groovy
अपनी build.gradle
फ़ाइल में, यह विकल्प जोड़ें:
android {
...
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
Kotlin
अपनी build.gradle.kts
फ़ाइल में, यह विकल्प जोड़ें:
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
या लिंकर फ़्लैग को इस तरह अपडेट करना होगा:
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")
कोड ठीक करना और रनटाइम से जुड़ी समस्याएं हल करना
भले ही, आपका ऐप्लिकेशन 16 केबी के हिसाब से अलाइन किया गया हो, लेकिन अगर आपके कोड में कहीं यह अनुमान लगाया गया है कि डिवाइस में किसी खास साइज़ का पेज इस्तेमाल किया जा रहा है, तो आपके ऐप्लिकेशन में गड़बड़ियां हो सकती हैं. इससे बचने के लिए, यह तरीका अपनाएं:
कोड लॉजिक में,
PAGE_SIZE
के लिए हार्ड कोड की गई सभी डिपेंडेंसी हटाएं. इसके अलावा, ऐसे इंस्टेंस भी हटाएं जो यह मानते हैं कि किसी डिवाइस का पेज साइज़ 4 केबी (4096
) है.इसके बजाय,
getpagesize()
याsysconf(_SC_PAGESIZE)
का इस्तेमाल करें.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 केबी वाले एनवायरमेंट में अपने ऐप्लिकेशन की जांच करनी होगी. इससे यह पता चलेगा कि आपके ऐप्लिकेशन में कोई समस्या है या नहीं. ऐसा करने के लिए, इन चरणों का अनुसरण करें:
टेस्टिंग के लिए इनमें से कोई एक एनवायरमेंट सेट अप करें:
अपना टेस्ट डिवाइस चालू करें. इसके बाद, यह पुष्टि करने के लिए कि वह 16 केबी एनवायरमेंट का इस्तेमाल कर रहा है, यह कमांड चलाएं:
adb shell getconf PAGE_SIZE
इस कमांड से
16384
वैल्यू मिलनी चाहिए.यह पुष्टि करने के लिए कि आपका ऐप्लिकेशन 16 केबी के हिसाब से अलाइन है, यह
zipalign
कमांड चलाएं. यहां APK_NAME, आपके ऐप्लिकेशन की APK फ़ाइल का नाम है:zipalign -c -P 16 -v 4 APK_NAME.apk
अपने ऐप्लिकेशन की पूरी तरह से जांच करें. साथ ही, उन जगहों पर फ़ोकस करें जिन पर पेज के साइज़ का रेफ़रंस देने वाले कोड के इंस्टेंस में बदलाव का असर पड़ सकता है.
Android 15 की 16 केबी वाली सिस्टम इमेज की मदद से, Android एम्युलेटर सेट अप करना
Android एमुलेटर का इस्तेमाल करके 16 केबी का एनवायरमेंट सेट अप करने के लिए, यह तरीका अपनाएं:
16 केबी वाली, Android 15 एमुलेटर सिस्टम इमेज, Android Studio Jellyfish | 2023.3.1 या इसके बाद के वर्शन के साथ काम करती हैं. हालांकि, 16 केबी वाले डिवाइसों के साथ काम करते समय बेहतर अनुभव पाने के लिए, Android Studio के Ladybug | 2024.2.1 या इसके बाद के वर्शन का इस्तेमाल करें.
हम नई सुविधाओं पर लगातार काम कर रहे हैं. इसलिए, Android Studio के नए वर्शन या नए प्रीव्यू वर्शन के उपलब्ध होने पर, उन्हें डाउनलोड करें.
याद रखें कि Android Studio का मौजूदा वर्शन इंस्टॉल किया जा सकता है, क्योंकि एक साथ कई वर्शन इंस्टॉल किए जा सकते हैं.
Android Studio में, टूल > SDK मैनेजर पर क्लिक करें.
एसडीके प्लैटफ़ॉर्म टैब में, पैकेज की जानकारी दिखाएं को चुनें. इसके बाद, Android VanillaIceCream या इसके बाद के वर्शन वाले सेक्शन को बड़ा करें और अपनी ज़रूरत के हिसाब से, यहां दी गई एमुलेटर सिस्टम इमेज में से एक या दोनों को चुनें:
- Google API एक्सपेरिमेंटल 16 KB पेज साइज़ ARM 64 v8a सिस्टम इमेज
- Google API का एक्सपेरिमेंटल वर्शन, 16 केबी वाला पेज साइज़, Intel x86_64 Atom सिस्टम की इमेज
आपने जो सिस्टम इमेज चुनी हैं उन्हें डाउनलोड करने के लिए, लागू करें > ठीक है पर क्लिक करें.
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 या उसके बाद के वर्शन के लिए, यह तरीका अपनाने की ज़रूरत नहीं है.
- डिवाइस मैनेजर में, 16 केबी की इमेज के बगल में मौजूद तीन बिंदुओं पर क्लिक करें. इसके बाद, डिस्क पर दिखाएं पर क्लिक करें.
- इस फ़ोल्डर में,
config.ini
फ़ाइल ढूंढें. config.ini
फ़ाइल में यह लाइन जोड़ें और बदलाव सेव करें:kernel.parameters = androidboot.page_shift=14
अपने बदलावों की पुष्टि करने के लिए, यह कमांड चलाएं. इससे आपको
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 से Android 15 और उसके बाद के वर्शन वाले डिवाइसों पर, 16 केबी के पेज साइज़ के साथ काम करने के लिए, उन्हें टारगेट किया जा रहा है.
साथ काम करने की इस ज़रूरी शर्त के बारे में ज़्यादा जानने के लिए, यह ब्लॉग पोस्ट देखें.